THE SAGE AIR DEFENSE SYSTEM • A Personal History Jacobs 






T H E 



AIR DEFENSE SYSTEM 



MITRE 





















THE SAGE AIR DEFENSE SYSTEM 

A PERSONAL HISTORY 






THE SAGE AIR DEFENSE SYSTEM 

A PERSONAL HISTORY 


JOHN F. JACOBS 


The MITRE Corporation 
Bedford, Massachusetts 



®1986 by John F. Jacobs 

All rights reserved. Published 1986. Second printing 1990. 

Printed in United States of America. Reproduction of this book, in part or in whole, is 
strictly prohibited. For copy information, contact The MITRE Corporation, Corporate 
Archives, Burlington Road, Bedford, Massachusetts 01730. 


Library of Congress Cataloging-in-Publication Data 
Jacobs, John F. 

The SAGE Air Defense System. 

1. SAGE (Air defense system) — History. 2. Jacobs, 
John F. I. Title. 

UG633.J24 1986 358.4'145'0285 86-16286 


Portrait of John F. Jacobs by Robert Berks 



To Mary 




CONTENTS 


Foreword .ix 

Preface .xiii 

A SAGE Chronology .xv 

Introduction . 1 

1 How I Came to the Digital Computer Laboratory. 5 

2 The Development of Whirlwind. 8 

3 The Digital Computer Laboratory Joins Lincoln Laboratory ... 16 

4 Contributions of Air Force Cambridge Research Center .18 

5 The Cape Cod System.22 

6 Whirlwind II .28 

7 Assignment to Group 62 .31 

8 Defining the Whirlwind II Arithmetic Element.36 

9 Jay Forrester and Company .39 

10 Selection of a Computer Contractor.43 

11 IBM Background . 45 

12 Lincoln Meets IBM .49 

13 The Hartford Meetings .55 

14 Project Grind . 60 

15 Genesis of the Systems Office .63 

16 From Boston to Poughkeepsie .70 

17 Features of the FSQ-7 .74 

18 Electronic Warfare.77 

19 Defining the SAGE System .82 

20 George Valley .. 86 

21 Ma Bell. ...90 

vii 



























22 Group 61 .94 

23 The RAND Corporation and SDC .96 

24 Genesis of Computer Programming in SAGE .99 

25 Meeting the Need for Programmers . 105 

26 Scheduling and Other Problems .108 

27 A Promotion and the Steering Committee.114 

28 SAGE Becomes Operational .117 

29 SAGE Systems Testing .122 

30 Division 4.126 

31 The Task of Integration.130 

32 Air Force Reaction and the Beginning of MITRE .135 

33 Halligan . 144 

34 Leaving Lincoln and Joining MITRE .149 

35 From SAGE to BUIC .155 

36 The Winter Study . 160 

37 The Mystique of System Engineering .164 

38 Summing Up . 168 

Epilogue..171 

The Romance of Programming ...175 


viii 






















FOREWORD 


SaGE was a remarkable development that had profound effects 
on the development of computers, information systems, and military 
capability. Many capable people were involved in its creation, in the Air 
Force, at MIT, and in industry, and a number of articles have been written 
about the project and a few of its leaders. This memoir is the first inside 
story of the project and how it looked and felt to those who were involved. 
Jack Jacobs is one of the great participants in the SAGE program; his 
contributions, largely unrecognized outside those who worked with him, 
were fundamental to success. I have known Jack for 35 years now. He is a 
modest man but a first-rate engineer and manager, and a major contributor 
to the art of large information systems. His memoir tells us much about 
SAGE, about how it was to work within a large pioneering development, 
and about Jack himself. 

I was at the MIT Lincoln Laboratory in the early 1950s as an 
associate division head, working on the design of the SAGE computer. I 
had transferred to Lincoln with the Digital Computer Laboratory. The 
division was growing rapidly; we had moved to another larger building, 
and I found that the closely knit old group, where eveiyone knew everyone 
else, was becoming a memory. 

One day, a tall, good-looking young fellow approached me with 
a question. He introduced himself as John F. Jacobs, our newly acquired 
graduate student assigned to the logical design of the adder in the comput¬ 
er’s arithmetic element. He knew I had done the logical design of the 
Whirlwind computer and wanted to know why Whirlwind’s adder design 
wasn’t satisfactory. As I recall the occasion, I gave him a brief and 
somewhat lofty lecture on adders, told him the Whirlwind adder was really 
quite satisfactory, but suggested he make a new review of the possibilities. 
He looked at me with a mixture of curiosity and courtesy and disappeared. 
I thought I had handled it pretty well, and that he would review the 
alternatives and agree that mine was best. Imagine my surprise when, 
some time later, I found out he had come up with an improved design. This 
first contact with Jake, as we all called him, turned out to be typical. He 
was curious and courteous, did his homework, and came up with an 
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improved design. Neither of us realized at the time that this first meeting 
was the beginning of a long and effective partnership. 

As Jake describes at greater length in this memoir, we came to 
know each other well while working with IBM in Poughkeepsie, New 
York. In this short time Jake had become one of the senior MIT design 
engineers. IBM had the job of engineering design and manufacture of the 
SAGE computer under Lincoln’s overall technical direction. “Direction” 
meant traveling to Poughkeepsie every week and arguing out the design 
with the IBM engineers. Public transportation was inconvenient and we 
usually drove, a 4 1 /2-hour trip. This meant leaving Boston at 5:00 in the 
morning and starting work at IBM at about 9:30. A day or two later we 
would leave Poughkeepsie at about 6:00 P.M., arriving home around 
11:00. Over the course of a few months, we all had a chance to ride with all 
members of the group. After exhausting the technical discussions, we 
naturally turned to each other’s personal lives and backgrounds. 

Jake was especially adept at telling stories of his early life in 
North Dakota. The snow, the grain elevators, and the poached deer all 
came alive to us in the dark car in the Connecticut hills. My clearest 
recollection, however, is of his tales of his education at “Meat Boners” 
college. I almost came to believe there was such a place and that the people 
of his hometown really did go down to the station to see him off, the local 
boy setting forth to make good in the big world. 

We took turns driving, and Jake’s turn always raised my anxiety 
the most. We would be moving fast, and ahead would be a stoplight with a 
line of cars. It was absolutely inevitable that we had to stop, but Jake 
would keep speeding on, talking all the while, and at the last possible 
moment, he would cram on the brakes and come to a shuddering stop. He 
maintained that he had learned to drive this way in North Dakota where 
there were few cars and no stoplights, and where coming to a stop was 
considered an emergency procedure. His part of North Dakota was laid out 
in sections and he claimed that he had trouble with turns because he hadn’t 
learned to make them until he left home. That may be true; but as far as I 
know, he never had an accident. 

Not long after this, we began to cope with the problems of being 
a relatively small group at Lincoln without legal authority, trying to 
maintain technical control of the very large SAGE program involving 
many government agencies and many contractors. The usual approach to 
such a problem is authoritarian: decide what to do, tell everybody to do it. 
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and make sure that they do. It wasn’t at all clear that we wanted to run 
things that way, and it wasn’t at all clear that Lincoln could make its orders 
stick if we tried. There were too many others and too few of us. Jake came 
up with the idea of the Systems Office, whose job it was to find and foresee 
problems and to get the large masses of people involved to understand and 
agree on appropriate action. Jake’s view was to use leadership. He would 
analyze the problems, propose solutions, and get everybody together to 
agree. “Thousand-man meetings,” they were called. They worked 
because everyone wanted the problems solved and no one (besides us) 
wanted to take responsibility for the whole system. Success was dependent 
on sound and thorough homework, however, and this is where Jake 
excelled. His willingness and his ability to do whatever was necessary to 
make a program come out right were his most distinguishing characteris¬ 
tics and among the chief reasons he played such a major role in the design 
of SAGE and in the creation of The MITRE Corporation. 

Once the SAGE hardware was well under way, Jake assumed 
direction of the software part of the job. The specification and preparation 
of the necessary computer programs turned out to be an enormous under¬ 
taking. The Lincoln group of less than one hundred, which had been 
preparing operational, test, and support programs for the prototype, was 
augmented by a new organization, System Development Corporation, 
with thousands of new and untrained people. Overnight, the Lincoln 
people became supervisors and Jake’s skills were needed to make the new 
situation work. He dove in with his usual combination of friendliness, 
firmness and hard work. I used to go to his organizational meetings from 
time to time and noticed that the charts on his blackboard were filled with 
misspelled names. He maintained that he had never learned to spell, but I 
felt no one could be that bad and accused him of deliberately misspelling in 
order to cover up his real mistakes. I now think I was right but for the 
wrong reason. He had many new people to deal with and was bound to 
misspell some names. But, he deliberately misspelled many, not to cover 
up for his mistakes but so that no one would feel too unimportant to be 
spelled correctly. He was concerned about them, not about himself. 

Throughout our careers at both Lincoln and MITRE, we were 
called upon to work with many Air Force officers at all levels. In such 
situations there is always tension between the need for indepen¬ 
dence, which is necessary to maintain quality and effectiveness in the long 
run, and the need for responsiveness, which is necessary to maintain 
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effectiveness in the short run. Jake spent a great deal of time making sure 
that there was the complete understanding required between the two 
groups to make the system work and work smoothly. He genuinely liked 
and respected the Air Force officers, and they in turn liked and respected 
him. He made many lasting friendships while assuring that the job went 
forward with a minimum of conflict. 

The first SAGE center went operational on July 1, 1958. Later 
that year, The MITRE Corporation was formed to cany on the system 
engineering for SAGE and, as it turned out, for many other systems as 
well. By 1958,1 was head of the SAGE design division at Lincoln and Jake 
was my associate. Together we organized MITRE, talked our associates 
into transferring from Lincoln to MITRE, and began the long task of 
building MITRE into an effective, first-rate professional organization. 
MITRE is another story, but Jake and I worked together as a team until 
Parkinson’s Disease forced his early retirement some ten years ago. 
Throughout our long association, his courage, his intelligence, his concern 
for me, for the job, for the organization, for everyone, have never failed. 
Our friendship is one of the great pleasures of my life. 

Jake is still telling stories, from Meat Boners to SAGE; from 
fancy to real accomplishment. I think you will enjoy this memoir of a great 
experience. 


Robert R. Everett 



PREFACE 


This is my story of the development of the SAGE (Semi-Auto¬ 
matic Ground Environment) air defense program. At the time of its 
operational deployment beginning in 1958, the SAGE system was the first 
military program to utilize a large-scale, real-time digital control computer 
supporting a major military mission. The development of the system was 
initiated at a time when the perception among Department of Defense 
(DOD) officials was that Soviet bombers carrying nuclear bombs were a 
primary threat to the United States. The generally held belief in the validity 
of this threat gave the SAGE program the highest DOD priority, and the 
DOD was willing to cover whatever costs were necessary to counter the 
threat. The SAGE design, including its architecture, components and 
computer programs, drew on R&D efforts throughout the United States, 
but it drew mostly on work being done at MIT on Project Whirlwind, at the 
Air Force Cambridge Research Laboratory, at IBM, AT&T, the Burroughs 
Corporation, and the RAND Corporation. 

These memoirs were designed to describe how it was to be a part 
of this large and complicated program. They cover the period from the late 
1940s to the early 1960s, which includes the time taken up by the concep¬ 
tion, design, development, manufacture and installation of SAGE. They 
were written to complement a documented history of the SAGE program, 
being prepared by historians Kent C. Redmond and Thomas M. Smith. 

By the time I became involved in SAGE, much of the conceptual 
and political framework for the project had already been settled. In the 
following pages, I will include enough of the background and chronology 
of the project to place my role in context. I was a middle-level manager 
caught up in events which were beyond my control, and yet I appeared to 
have as much control as anyone else. My contribution was mainly in the 
area of effecting a rational management control of the design of that 
system. As were most of those who participated, I was closer to some 
projects and people than to others, and, as a consequence, those are the 
people and projects I have emphasized here. We decided to add pictures of 
some of the people who played major roles in the SAGE job and of those 
who are mentioned in this book. The choice of photographs was based 
mainly on their availability, and by no means attempts to represent all or 



even most of the important people, but rather, illustrates the diversity of 
the participants’ backgrounds, organizational positions, and experience. I 
don’t claim that everything reported in this book was “reality.” To some 
extent, my own memories are colored by the memories of others who have 
discussed these events with me, and the repetitions have created a modi¬ 
fied picture of my reality. This, then, is my memory of the events at the 
time they occurred, and of the people as I saw them then. 

Giving credit to all those who assisted in the preparation of this 
volume would require the better part of these pages, but I’ll try to mention 
those who assisted me throughout the course of its preparation. Most 
prominent among these people was Louise Meyer, an editor for MITRE. 
Louise managed the integration of the various parts of the piece as it was 
developed over the course of several years. Her insight and good judgment 
have materially improved on what I had originally prepared. In addition, 
Charlotte and Gerry Klein volunteered their services as readers and 
assisted in the critical review of the chapters as they were developed. In the 
historical research required to verify the content and chronology of events, 
Louise Sullivan, Edward Galvin and David Baldwin of MITRE Archives 
spent a large fraction of their time in support of the entire project. And 
from the beginning, I was supported by the Word Processing Center’s Fran 
Jonuskis, with help from Bobbie Statkus. Fran made it possible forme to 
have several reviews of the text as it progressed. Many people read the 
piece for content and offered criticism, ideas, anecdotes and support. 
Their time spent considering the manuscript and their comments and 
suggestions were appreciated. But this project could not have progressed at 
all if not for Bob Everett and Charlie Zraket, who provided me with 
encouragement and with access to MITRE services. 
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A SAGE CHRONOLOGY 


1949 

Aug. Russians detonate atomic device. 

Nov. George E. Valley, MIT, proposes to Theodor von Karman, chairman, 

Air Force Scientific Advisory Board, that a study of air defense require¬ 
ments be undertaken. 

Dec. Air Defense Systems Engineering Committee (ADSEC) is established, 

with Valley as chairman. 

1950 

Sep. First MIT experiments transmitting digitized data from Microwave 

Early Warning (MEW) radar at Hanscom Field (Bedford, Mass.) to 
Whirlwind computer in Cambridge, Mass., over commercial telephone 
lines. 

Oct. ADSEC’s final report is issued, defining the air defense system that will 

become known as SAGE. 

Dec. Gen. Hoyt S. Vandenberg, Air Force Chief of Staff, asks MIT to 

establish and administer an air defense laboratory, and to perform an 
intensive investigation of the air defense problem. 

1951 

Jan. Air Force contracts with Bell Telephone Laboratories to improve exist¬ 

ing ground-radar-based air defense system. 

Jan. Air Force contracts with University of Michigan to expand ballistic 

missile program into a system for air defense. 

Feb. “Project Charles” established at MIT for short-term investigation of air 

defense problem. 

*Previously published by AFIPS Press in an article by the author entitled “SAGE Over¬ 
view,” appearing in Annals of the History of Computing, Vol. 5, No. 4, October 1983, pp. 
328-329. 
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Apr. 

Jul. 

Aug. 

Oct. 

Feb. 

Apr. 

May 

Jun. 

Jul. 

Oct. 

Jan. 

Jan. 

Mar. 

May 

Jun.-Jul. 
Summer 

Aug. 


First live demonstration of automatic aircraft interception using Whirl¬ 
wind computer and MEW radar. 

“Project Lincoln” established at MIT as laboratory for air defense — 
original charter for MIT Lincoln Laboratory. 

Air Force Air Research and Development Command (ARDC) assumes 
responsibility for administration of Project Lincoln. 

MIT’s Whirlwind staff at the Digital Computer Laboratory joins Project 
Lincoln as Division 6. 


1952 

Secretary of the Air Force T.K. Finletter assigns top priority to air 
defense matters; promises MIT whatever funding required. 

Name “Project Lincoln” changed to “Lincoln Laboratory.” 

Memory Test Computer (MTC) under design. 

Plans for “Cape Cod System” published — scaled-down simulation of 
nationwide SAGE system. 

Lincoln considering several manufacturers for production of air defense 
computer. 

IBM awarded subcontract by Lincoln to study computer project; Divi¬ 
sion 6-IBM engineering collaboration under way. 

1953 

Lincoln publishes Technical Memorandum No. 20 — a proposed air 
defense system called “Lincoln Transition System.” 

First Division 6-IBM technical meeting, Hartford, Conn. 

Lincoln publishes report, “Cape Cod System and Demonstration.” 

ARDC decides to pursue Lincoln Transition System and phase out 
University of Michigan system. 

Division 6-IBM “Project Grind” meetings. 

Division 6 staff moves from MIT in Cambridge to Lincoln Laboratory 
in Lexington. 

First bank of core storage wired into Whirlwind after MTC tests 
succeed. 
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Sep. IBM receives contract to produce two single-computer prototypes: the 

XD-1 and XD-2. 

Sep. Cape Cod System fully operational. 

1954 

Nov. Decision made to have duplex computer system. 

Dec. Cape Cod System tracks 48 aircraft. 

Feb. First production contract for SAGE computer — called the AN/FSQ-7 

— awarded to IBM. 

May Air Materiel Command establishes Air Defense Engineering Services 

(ADES) at Wright-Patterson Air Force Base for acquisition of the 
Lincoln Transition System. Western Electric becomes involved in 
ADES management. 

Jul. Lincoln Transition System is renamed SAGE — Semi-Automatic 

Ground Environment. 

Sep. ADES moves to New York City and acquires representatives from 

ARDC, ADC, and AMC. 

1955 

“Red Book” operational plan is published — complete definition of 
SAGE. 

ADES becomes part of newly formed Electronic Defense Systems 
Division. 

Simplex version of AN/FSQ-7 (XD-1) installed at Lincoln by IBM. 
System Development Division emerges from RAND Corporation. 

1956 

Feb. Development of TX-0 announced — experimental transistorized com¬ 

puter. 

Apr. Lincoln urges Air Force to find agency to manage integration of 

weapons with SAGE system. 

Jun. IBM’s first production FSQ-7 system accepted in manufacturing test 

cell. 


Mar. 

Apr. 

Jun.-Jul. 
Dec. 
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Sep. Air Force asks Lincoln to manage weapons integration task; Lincoln 

declines. 

Nov. ARDC holds conference on weapons integration problem. 

Dec. Experimental SAGE Sector (ESS) begins shakedown tests. 

Dec. System Development Division of RAND begins independent operation 

as System Development Corporation. 

1957 

Dec. ARDC recommends establishment of Air Defense Systems Manage¬ 

ment Office (ADSMO) to oversee integration. 

May SAGE Weapons Integration Group (SWIG) assembles at Hanscom 

Field. 

Jun. Lincoln urges that Division 6 take over weapons integration responsi¬ 

bility. 

1958 

Mar. Secretary of the Air Force proposes to MIT that a new organization be 

formed to provide systems engineering support to ADSMO. 

Mar. To strengthen ADSMO, Air Defense Systems Integration Division 

(ADSID) is established. 

Jul. First of 24 SAGE direction centers operational at McGuire Air Force 

Base, New Jersey. 

Jul. Division 6 becomes basis of new systems engineering organization, 

incorporated as The MITRE Corporation. 

1959 

Jan. Transfer of technical personnel from Lincoln to MITRE. 

Nov. Air Force Command and Control Development Division (C 2 D 2 ) acti¬ 

vated at Hanscom Field, takes over ADSID mission. 

1960 

Feb. Gordon Thayer of AT&T named director of Winter Study. 
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Mar. 

Apr. 


Dec. 


1961 

ARDC redesignated Air Force Systems Command (AFSC). 

Electronic Systems Division (ESD) of AFSC activated at Hanscom 
Field under Maj. Gen. Bergquist; includes former AFC 2 D 2 . 


1962 

ESD and MITRE sign memorandum of agreement establishing a basis 
of cooperation. 


1963 

The SAGE system is fully deployed in 23 air defense sectors: 22 in the 
United States and one in Canada. 
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INTRODUCTION 


EVOLUTION OF AIR DEFENSE 
OF THE UNITED STATES: 

A BRIEF REVIEW 


Uuring the First World War, the airplane was used for surveil¬ 
lance and, late in the war, for some bombing. It did not play a very 
significant role in that war, but the potential was evident. The surveillance 
(reconnaissance) role of aircraft during this war, carried on by tethered 
balloons and aircraft, led to the need of maintaining air superiority. Later, 
as larger airplanes were developed which could carry bombs, aircraft 
began to play a role in defense. In the twenties, the future importance of air 
power was dramatically demonstrated by Billy Mitchell’s post-war efforts 
in sinking the captured German battleship “Ostfriesland” and the Ameri¬ 
can battleships “Texas” and “Indiana.” He illustrated the possibilities for 
the utilization of bombers as a strategic force. 

The air defense of the United States before 1935 had a low 
priority. Canada and Mexico were both friendly, and the Atlantic and 
Pacific served as effective barriers against land-based aircraft of the time. 
This complacency began to erode by the time of the Spanish Civil War 
when German and Italian aircraft were employed with considerable effect 
on the side of the rebels. 

About the same time Great Britain, anticipating possible con¬ 
frontation with Germany, began the development of radars. By adapting a 
high-frequency radio device (a sounder) for measuring the height of the 
ionosphere, Sir Robert Watson-Watt created the first British radar around 
1935. The angular accuracy of this radar was poor, but the range accuracy 
was good. Its first demonstrations were at ranges of less than ten miles. 
With the invention less than four years later of the cavity magnetron, an 
efficient generator of microwave power, ranges of hundreds of miles with 
good angular accuracy were achieved. 

The British developed a chain of radars along the coast of Great 
Britain called the “chain home” radar system. With aircraft being guided 
to invading bombers by radar rather than by sight, the British were able to 
use their air fleet much more efficiently. The British also developed 
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airborne radar which aided interception at night. During the Battle of 
Britain, when Germans deployed both day and night bomber missions in 
large numbers over the British Isles, the British chain home radar system 
made it possible for British fighter/interceptors to stay on the ground until 
it was absolutely necessary. They were then vectored by the radar systems 
to the German bombers. The British system became the model for United 
States air defense systems. The British had other, highly classified meth¬ 
ods of locating German aircraft. Early in World War II, they had broken 
the German cryptographic code, and thus had access to the orders being 
given to the German aircraft. The precise locations and times of German 
attacks could thereby be used directly by British fighter commands. 

The need for air defense was driven home in the United States in 
1941 by the Japanese with their attack on Pearl Harbor. Pearl Harbor 
demonstrated the need for surveillance and warning and real-time control. 

Sobered by these events, the United States became serious about 
air defense within its continental limits and, near the end of World War II, 
there were more than 70 radar stations known as Ground Control Intercept 
(GCI) sites. This network of GCI sites became known as the “Manual 
System.” 

Each of these GCI sites consisted of one or two search radars, a 
height-finder radar, ground-to-air and air-to-ground communications. The 
operators sat in front of plan position indicator (PPI) scopes, which 
presented the air situation on a scope that employed long-persistence 
phosphors. Aircraft appeared as “blips” of light on the face of the tube, 
and information on targets from adjacent sites was cross-told by voice 
telephone. The control centers were usually built around a large, edge-lit 
plexiglass board which showed the local geographic features. Aircraft of 
interest and status information were marked on the board with grease 
pencils by operators who worked standing on scaffolding behind the 
board. 

The GCI sites were spread along the East and West Coasts, with 
some in Mexico and Canada. There was also a Ground Observer Corps of 
more than one million volunteer observers. But, as V-E Day approached 
and it became clear that it was only a matter of time until Japan surren¬ 
dered, the priority of United States air defense was again lowered, and 
support of the existing sites began to erode. After V-J Day, when the Allies 
had won and the United Nations was instituted, and when the most 
powerful air forces were in the hands of the Allies, including Russia, there 
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seemed no justification for the expense of maintaining the radar sites 
established during the war. 

This attitude began to change, however, as it became clear that 
the Russians were bent on creating a different political order and clamped 
down the Iron Curtain. In June, 1948, Berlin was cut off. The Berlin airlift 
began shortly thereafter and was a further demonstration of what could be 
done with air power. The United States became determined to be second to 
none in the areas of strategic war. 

In 1947, the Air Force was organized as a service separate from 
the Army, reporting to a newly established Defense Department. The Air 
Force was given the air defense mission and proceeded to plan the revival 
of the Manual System. The importance of this mission was increased with 
the subsequent Russian achievement in 1949 of producing atomic bombs, 
and was further strengthened by later events in Korea. While these events 
were evolving, the Air Force Chief of Staff, General Hoyt S. Vandenberg, 
became more and more concerned about United States vulnerability to 
airborne attack. The Air Force Scientific Advisory Board, under Dr. 
Theodor von Karman, was exposed to the problem, and in 1949, the Board 
set up an Air Defense Systems Engineering Committee (ADSEC) under 
George E. Valley, a physics professor at the Massachusetts Institute of 
Technology. 

The Valley Committee began by looking at the newly reactivated 
air defense system. This system had been authorized by Congress through 
the Air Force, and consisted of many of the 70 or so GCI sites which 
constituted the Manual System set up during World War II with improved 
radars and height finders. The Valley Committtee quickly concluded that 
the air defense system, as reshaped by the Air Force, had a very low 
capability, and characterized it in their report as “lame, purblind and 
idiot-like.” 

The Committee recommended that a competent technical organi¬ 
zation look into what could be done to improve the system in the short run. 
The Committee also suggested that a longer range look be taken at the 
problem. It recommended the extensive use of automation, particularly 
computers, to handle the bookkeeping, surveillance and control problems 
in the implementation of next generation air defense systems. This conclu¬ 
sion was partially driven by the fast-developing Whirlwind computer at 
MIT. The Whirlwind promised to provide real-time control over a large 
number of aircraft. It was also noted that the ability to pass digital 
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information over phone lines had been demonstrated at the Cambridge 
Research Laboratory and at Bell Telephone Laboratories. To deal with one 
of the major problems, low altitude surveillance, the Committee recom¬ 
mended the establishment of a large number of short-range, low-mainte¬ 
nance radars, more than in the current system, which would be placed 
closely together to fill gaps in coverage. 

The Valley Committee report triggered General Vandenberg to 
ask MIT to study the entire problem of continental air defense. Accord¬ 
ingly, MIT set up a study called Project Charles under Professor F. 
Wheeler Loomis, on leave from the University of Illinois, and brought in a 
number of distinguished scientists, including George Valley, from a broad 
spectrum of the United States scientific community. Valley, supported by 
most of the participants, was given the task of defining, insofar as it could 
be done, the longer range air defense system. The Charles Study recom¬ 
mended first that the existing system be upgraded (this was the task of the 
Western Electric Company and Bell Laboratories, and was known as the 
Continental Air Defense Survey, or CADS, project). Second, it recom¬ 
mended that a laboratory be created to deal with the research problems 
associated with the development of a more capable “transition system.” 
This laboratory was established within MIT, and in 1952 was endorsed as 
the MIT Lincoln Laboratory. Work was also to be carried on there toward a 
future ultimate system. The transition system would become known as 
SAGE, for Semi-Automatic Ground Environment. 

For the next ten years, there would be a strong and sustained 
effort, led by Lincoln Laboratory, to realize a solution to the air defense 
problem. 
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CHAPTER 1 


HOW I CAME TO THE DIGITAL 
COMPUTER LABORATORY 


I stumbled into the SAGE milieu by chance. In 1950, I was an 
MIT graduate student, married, with two children. I was unhappy with one 
research assistant job and looking for a different one to help pay the way 
through graduate school. I did not know when I happened upon a job at 
MIT’s Digital Computer Laboratory the scope of the undertaking with 
which I would become involved. This undertaking was the design and 
development of the air defense systems of the United States. 

I had been working at the MIT Research Laboratory of Electron¬ 
ics (RLE) since September 1950. RLE was formed, in part, from the 
residue of the famous MIT Radiation Laboratory that had been established 
during World War II to develop microwave radar. RLE was headed at that 
time by Professor Albert G. Hill of the Physics Department. Hill had been 
a division head in the Radiation Laboratory. His division, devoted to 
transmitter components, was one of the larger divisions. Later, Hill would 
join Lincoln Laboratory as its second director, bringing with him many of 
the people who had worked for him at RLE. MIT’s research assistant 
program paid me $135 per month plus tuition. These monies, along with 
the $95 per month I received under the GI Bill as a Navy veteran, made it 
possible for me to work toward a master’s degree in Electrical Engineering 
while working at RLE. 

My assignment at RLE was to Professor William H. Radford, 
later associate director and then director, Lincoln Laboratory, who was in 
charge of a telemetry section. Indirectly, this section worked for Professor 
Robert C. Seamans, Jr., of the Aeronautical Engineering Department 
(later he became associate director of NASA and then secretary of the Air 
Force). Seamans had the responsibility for a ground-to-air missile project 
called Project Meteor, and Radford had been subcontracted to provide the 
telemetry for it. 

Although I was technically assigned to Radford, I seldom saw 
him. He had several offices, and he always seemed to be in transit from 
one to another. So it was actually Benjamin J. Dasher, a doctoral student 
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and professor of electrical engineering on leave from Georgia Tech., who 
was in charge of the group. There were eight or nine people in that group 
— primarily graduate students — working on various aspects of the Meteor 
telemetry. Among them was Walter E. Morrow, Jr., who would later 
become director of Lincoln Laboratory. 

The organization of the telemetry section was very loose, and 
each member of the group was more or less free to choose his own project. 
It was expected that our projects would result in something of use to the 
Meteor program and at the same time pave the way toward a thesis topic. I 
tried to do some work on a miss distance indicator, a sensing device that 
would measure how close Meteor got to its intended target, but with the 
demands of the course work, the nebulousness of my assignment, and the 
general feeling that no one cared, I didn’t do very well that year at RLE. 

I happened to have a professor, Dr. William K. Linvill, who had 
been using the Whirlwind computer, which was then in its final stages of 
development at MIT, to do some studies that contributed to his field of 
network analysis. I became friendly with Bill Linvill, and he piqued my 
curiosity about the Digital Computer Laboratory, where Whirlwind was 
being developed. I think it was he who told me that the laboratory was 
looking for more people. With that information, I went to the laboratory 
and spoke with John C. Proctor, who was then acting in an administrative 
capacity handling personnel functions. 

Proctor confirmed that there were job openings at the Digital 
Computer Laboratory that would be appropriate for me. He showed me 
around the Barta Building which was the Computer Laboratory’s home. In 
the basement there was a tube shop where the laboratory was producing its 
own high-speed memory tubes. On the upper floors was the Whirlwind 
machine. My first impression of the computer was of rows and rows of 
racks with bundles of wire everywhere and thousands of vacuum tubes. In 
the week or two following my discussion with Proctor, I discovered that a 
number of people who lived where I did, in Westgate West (a community 
of renovated Navy barracks converted to apartments for married students 
at MIT), also worked at the Digital Computer Laboratory. Everyone I 
spoke with confirmed that the Computer Laboratory was a good place to 
work. 

I also met David A. Huffman who was on a doctoral program and 
whose thesis advisor was Dr. Samuel Caldwell, who had collaborated with 
Dr. Vannevar Bush on the MIT differential analyzer. During the time I was 
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looking into the computer field, Dave told me about a course taught by 
Caldwell on logical design and Boolean algebra. All this interested me, so 
in the summer of 1951,1 made arrangements to transfer from the Research 
Laboratory of Electronics to the Digital Computer Laboratory, and I 
signed up for Caldwell’s courses. I went around to see RLE’s director, A1 
Hill, to tell him about my transfer. He said he didn’t care, and so I left. 

Thus, I didn’t get to know, or see for that matter, A1 Hill until I 
was leaving RLE. Hill had the reputation for being an up-and-coming 
senior member of the MIT research organization. An incorrigible punster, 
he was a round-bodied, round-faced, cherubic person, who reminded me 
of Burl Ives. He was also reputed to like an occasional drink. Hill was to 
indirectly affect my career throughout my involvement with the air defense 
systems. 

I found the atmosphere at the Digital Computer Laboratory quite 
different from that at RLE. Everyone seemed to feel he was doing some¬ 
thing important and interesting. Although there didn’t appear to be any 
more formal organization than there was at RLE, there was a kind of 
invisible control structure in operation. People seemed to know what they 
were trying to do. It became clear after a while that the organization was 
very carefully managed by Jay W. Forrester and his associate director, 
Robert R. Everett. However, I didn’t meet either for some time after I 
joined the laboratory. 
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CHAPTER 2 


THE DEVELOPMENT OF WHIRLWIND 


I he Whirlwind project evolved out of a Navy program estab¬ 
lished during the war in the MIT Servomechanisms Laboratory under 
Professor Gordon S. Brown, the laboratory’s director, and Jay W. Forres¬ 
ter. It began as a program to create an airplane stability control analyzer 
(ASCA) for the Navy’s Special Devices Center. It was intended that this 
analyzer include a simulated airplane system, wherein a hydraulically 
operated, simulated cockpit would react to wind tunnel data and other 
environmental conditions, as well as to the aerodynamics of the proposed 
aircraft. It was expected that one could “fly” the airplane in a simulation 
mode before it was built. The ASCA could also be used for training. 

The key component of this airplane stability control analyzer was 
a computer. It was originally intended to be an analog computer of the sort 
developed during the war at MIT by Bush and Caldwell, but it became 
clear to Jay Forrester from discussions with Perry Crawford of the Navy 
Special Devices Center that the emerging digital computer technology 
promised more flexibility and capacity than could be generated by the 
then-existing analog computers. Sometime during 1946, Forrester decided 
to attempt to build a digital computer. Although there were a number of 
digital computers working or under development — primarily at the 
University of Pennsylvania, Princeton, Bell Laboratories, Harvard, and 
in industrial organizations such as IBM — these computers were dedicated 
to the solution of mathematical problems, and not to the problem of real¬ 
time control. Real-time problems required speed and reliability well 
beyond that which could be expected from the mathematically oriented 
developments. 

What had begun as an airplane stability control analyzer soon 
became a project to develop a general purpose digital computer to be used 
for a variety of real-time control problems. In 1948, the responsibility for 
Whirlwind was shifted from the Navy Special Devices Center to the 
mathematics branch of its parent organization, the newly established 
Office of Naval Research (ONR). Judgments as to Whirlwind’s direction 
and funding were made on the same basis as were the mathematically 
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oriented machines administered by the branch. Since the Whirlwind proj¬ 
ect consumed a large fraction of the mathematics branch budget, funding 
became a serious problem after the transfer. In 1949, however, the United 
States Air Force contracted with the Servomechanisms Laboratory to do a 
study of the uses of digital computers in air traffic control, and within a 
year, the prospects for obtaining Air Force funding for the air defense 
mission became a real possibility. Jay Forrester, at George Valley’s invita¬ 
tion, had participated in the Valley Committee (ADSEC) study and had 
laid the groundwork for Whirlwind support to air defense development. 
Sometime during this period, the Servomechanisms Laboratory set up the 
Digital Computer Laboratory (DCL) specifically for the Whirlwind 
project. 

The aircraft stability control analyzer, as well as the other real¬ 
time control applications which were thought to be possible with the use of 
the projected Whirlwind machine, dictated two basic design principles: (1) 
a systems architecture and components which provided the highest pro¬ 
cessing speed, and, (2) components and logical design which maximized 
reliability of operation. 

Speed of operation is necessary to assure that all the processes 
are completed when the answer is needed (thus, real time). Speed trans¬ 
lates into capacity to deal with a complex process such as the solution of 
many simultaneous differential equations, as in the ASCA system, or 
when a large number of similar processes are required in a given time, as in 
tracking in the air defense system. To obtain this capacity, the Whirlwind 
group chose to create a parallel machine, rather than a serial machine, 
which had been their original intent. Thus they could operate on whole 
numbers rather than a bit at a time. The group wanted to create a short 
memory cycle, very short transfer time, and very short calculation time, so 
the basic circuit development emphasized speed of operation. Fortunately, 
the World War II radar developments provided high-speed pulse circuits. 

The group chose a simple architecture for a parallel binary digital 
computer with single address instruction. It included a high-speed mem¬ 
ory, an arithmetic element, a control element and an input-output system 
— all operating on a common parallel bus. This architecture was refined 
and detailed in a set of block diagrams. The block diagrams group under 
Bob Everett became the watchdog over a number of groups devoted to the 
design and implementation of the necessary functional electronics needed 
to cause the logical blocks to work as predicted. A 16-bit parallel bus was 
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used to deal with the word length chosen by the block diagrams group. 
Sixteen bits was enough to supply the necessary dynamic range and 
accuracy required in most control applications, and it provided an instruc¬ 
tion word of appropriate length to accommodate the number of instructions 
and the number of memory addresses expected to be necessary. Sixteen 
bits was too short a word for mathematical or scientific calculations which 
generally require more precision, but for the real-time applications it was 
quite adequate. 

With reliability as the other priority of the machine, the Whirl¬ 
wind group adopted a policy of “try before buy.” It was important to test 
the basic circuits in a realistic environment to be able to predict, as the 
machine built up, its ultimate performance. It was this philosophy that led 
to the design and construction, under the guidance of Norman H. Taylor, 
of a five-digit multiplier, made up of the kind of circuitry which was 
expected to be used in the Whirlwind machine. This multiplier, using the 
vacuum tubes which were chosen as the system’s basic components, was 
operated continuously, solving the same problem and checking the 
answer, for weeks without failure. The purpose of the multiplier was to 
gather reliability data on the vacuum tubes and other critical components. 
The multiplier used about 400 vacuum tubes which were programmed on a 
read-only toggle switch memory. 

David R. Brown and two of his engineers, Edwin S. Rich and 
John A. (“Gus”) O’Brien, performed studies in depth on the characteris¬ 
tics and failure modes of the circuits and tubes that went into Whirlwind. 
They worked with the tube manufacturer, Sylvania, to correct what could 
be corrected. Since the Whirlwind component specifications were very 
tight and produced a tube that was over-specified for non-computer usage, 
direction of tube design and quality control was effectively taken over 
from Syl vania. One result of this careful attention was that these tubes cost 
from $5 to $10 apiece, which was high for the time. 

Three kinds of difficulties became evident with the vacuum tube. 
The first was mechanical failure due to faulty construction. Second were 
the problems with the cathode, which reacted with the oxide coating 
forming a barrier and causing it to act as a resistor rather than as a 
conductor. The third difficulty with the vacuum tubes was their gradual 
deterioration of performance over time. 

This last problem became an important aspect of the develop¬ 
ment of the Whirlwind computer. Noting that this deterioration could be 
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measured by various means, an important method of evaluating the margin 
of deterioration was conceived by Forrester. All of the circuits in the 
Whirlwind computer were subjected to this “marginal checking.” For the 
majority of the circuits that used one of the standard tubes (for example, 
the 7AK7), the screen voltage was lowered to simulate the deterioration. 
(In actual vacuum tube deterioration, the margin would become lower and 
lower until it was advisable to pull the tube before the failure occurred.) 
Thus, through a combination of working with the tube manufacturer to 
deal with the mechanical failures and the cathode barrier problem, and 
with the application of marginal checking, tube loss during computer 
operation was reduced to a tenth of a percent per thousand hours, which 
was a dramatic improvement over previous statistics. With the improved 
vacuum tubes and with marginal checking, the Whirlwind people stimu¬ 
lated the development of tubes of very high reliability. 

High-speed memory was also a problem. The speed of operation 
of the system depended on it. Many organizations were developing and 
using cathode ray tube storage devices, the most successful of which was 
the Williams tube. When the Whirlwind machine was conceived, this kind 
of memory was essentially the only choice available. The Digital Com¬ 
puter Laboratory set about the task of designing and fabricating its own 
electrostatic storage tube. Like all such tubes, it depended on using the 
electron beam as the device for selecting a spot on an insulator on which 
“ 1 ” or “0” could be stored, and on the beam’s ability to change the charge 
on an insulating plate. Mica was the first insulator to be used; others were 
to follow. 

In order to fabricate its own electrostatic storage tubes, the DCL 
set up a tube shop where tubes could be built and tested. The responsibility 
for managing the electrostatic storage tube project was Stephen H. Dodd’s. 
Steve had worked with Jay Forrester in the early part of World War II, 
when both men were in their early twenties. One of the lessons that was 
learned early in the game by the people who worked in the MIT laborato¬ 
ries was that a well-rounded engineer is one who participates in all of the 
stages of the development practice, from the conceptual to the operational 
phase, and that feedback from every phase modifies or tends to modify 
earlier phases. This approach creates the best product and involvement, 
but sometimes includes hazardous duty. Steve Dodd was an MIT graduate 
student at that time, working in the Servomechanisms Laboratory. He had 
done his thesis on the hydraulic transmission portion of a ship-board 
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antenna stabilizing device, designed to keep the antenna boresight on the 
horizon as the ship that carried the antenna on her mast was tossed about. 
The stabilizing system was Jay’s responsibility, and Steve was his princi¬ 
pal supporter. The stabilizing device was mounted aboard a lightship off 
the coast of New England, and Jay and Steve monitored its performance by 
observing it in operation. Steve relates a story of his experience during the 
test operation: fearing that the hydraulic fluid was too dirty and believing 
that a filter should be changed, Jay asked Steve to climb the mast to read a 
gauge that had been installed for the purpose of indicating the pressure of 
the fluid. Steve, who was not fond of heights, climbed the mast, taking all 
his courage. When he got to the top, he found that the gauge was color- 
coded. Steve was color-blind. He came down the mast and told Jay. 
Forrester grumbled something about research assistants not taking physi¬ 
cals to qualify for their work, and so he climbed the mast himself, but 
found that he couldn’t read the gauge either. They decided to change the 
filter, which would have made the climb unnecessary in the first place. 

When Whirlwind was conceived, the responsibility for the elec¬ 
trostatic storage tube memory was assumed by Steve, and Jay looked to 
him for its development. When Jay decided that the DCL would build its 
own tubes, Steve became a part of that effort. Steve was a conscientious, 
personable, thorough engineer, whose pleasant countenance was domi¬ 
nated by a wide smile. His eager and alert personality couldn’t help but 
make me think of Bugs Bunny’s energetic and wise ways. 

The tube shop, located in the basement of the Barta Building, 
reported to Patrick Youtz, who was a research associate (as distinguished 
from a research assistant). I think the difference was mainly that he was not 
a graduate student, but a full-time researcher with an academic appoint¬ 
ment. Youtz was a real character: stories attributed to Pat would have you 
believe that he had been a coal miner, a professional football player 
(Chicago Bears) and a lawyer. He was a large, powerfully built man and 
reminded me of Daddy Warbucks with a jet-black toupee. I was led to 
believe that he had learned about vacuum tube manufacturing while pre¬ 
sumably working at American Television, Inc., in Chicago. Coinciden¬ 
tally, I had also worked there before coming to MIT. I had not known 
Youtz then; for though he was supposed to have been there when I was, we 
may have worked in different divisions. 

American Television was headed by a man named U. A. Sana- 
bria, a Cuban who had come to the U.S. as a young boy. He claimed to be 
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one of the inventors of television and that he had set up a TV station in the 
Chicago area in 1925. He also claimed that he held a patent on interlace 
scanning on the flying spot disc scanner that was used in the first TV 
experiments. He had become associated with Lee de Forest, inventor of 
the vacuum tube. When I worked at American Television, they were 
manufacturing cathode ray tubes for television sets, and in addition were 
running a television engineering school, where I taught TV maintenance 
and theory as well as differential and integral calculus. When I was there, 
Lee de Forest was in his late seventies or early eighties. Each day he came 
to work in the laboratory on the top floor of the building, where he 
maintained a covey of German glass blowers and where he was alleged to 
have been working on experiments in vacuum tubes. He was a spry man. 
He and U. A. Sanabria seemed to be the antithesis of each other: Sanabria 
was a promoter; de Forest seemed to be a researcher. Sanabria was also a 
friend of “Mad Man” Muntz, the legendary Chicago used car dealer. 
Together, they manufactured a line of televisions under the name of Muntz 
TV. Sanabria and de Forest did have one thing in common, and that was 
their attraction to buxom blonde girls, who were hired for many of the 
secretarial, clerical and administrative positions. 

Whether Youtz had obtained his experience at American Televi¬ 
sion or not, by 1951 his DCL tube shop had managed to produce enough 
vacuum tubes so that a 16 x 16 (256 words) memory could be used with 
Whirlwind. The mean-time-to-failure of these tubes was very short; much 
too short for a practical system. In fact, in order to get anything near 
satisfactory performance, the engineers who were putting the memory 
together had to know the idiosyncrasies of each of the tubes that was used. 
One of those engineers, Alan J. Roberts, remembers one of the times he 
was asked to fix a problem with this memory system. One of the 32 tubes 
in the system had a mechanical fault in the signal plate assembly that was 
used for writing ones and zeros. Apparently, there was some play in the 
structure that held the signal plate screen in place. Several times when he 
was called in, A1 went directly to that particular tube, tapped it in a certain 
way, and cleared up the trouble. The necessity of an engineer’s knowing 
the weaknesses of the individual tubes, practically calling the tubes by 
name, promised to be the rule, and not the exception, in CRT memory. 

By 1953, a second bank of these tubes had been produced and 
installed. It is a credit to Steve Dodd, Pat Youtz and others that it worked as 
well as it did. Possibly, if they had concentrated further on the design, they 


13 



might have made a practical system. But in the meantime, largely due to 
the personal efforts of Jay Forrester, the first random-access magnetic core 
memory had been devised. Although the first operations of the Whirlwind 
machine used cathode ray tube memory, the core memory showed promise 
for the reliability and capacity required, but as Norm Taylor remarked 
tongue-in-cheek, the available cores were as big as doughnuts and the 
driving vacuum tubes were as big as coffee pots. After the magnetic core 
was substituted for the electrostatic memoiy tubes, the tube shop concen¬ 
trated on cathode ray tube displays, helping in the development of the 
“Charactron” and “Typotron” display tubes. The storage tube, however, 
seemed to peak out at a performance level well below that desired by the 
group. 

The core memory technology had to be developed practically 
from scratch. The assignment for guiding the development of cores for use 
in the projected random access core memory was given to Dave Brown. 
Dave hired Frank E. Vinal and John B. Goodenough, and enlisted the help 
of a Professor von Hippie from the MIT metallurgy department. They set 
up a core manufacturing facility where they made the cores that went into 
the first memories. 

To begin with, they selected a core size that was the smallest it 
could possibly be (while still practical) to assemble into the patterns of 
rows and columns that made up the various types of arrays. Once the small 
ceramic cores could be reliably produced, the problem of core array 
assembly and manufacturability was addressed. A jig was invented that 
held a large quantity of cores in a hopper, and automatically dropped the 
cores onto a grooved tray, and shook the tray until the cores settled into 
position in the grooves, where they were then sucked in by partial vacuum 
and aligned, so that they were then ready to be wired. The X and Y wires 
could be automatically installed with little difficulty through the appropri¬ 
ate rows and columns, and the excess cores swept off. However, the 
sensing wire had to be threaded through every single core, and this job had 
to be done by hand. 

In the course of core development, visitors came to MIT to see 
how things were done. John Goodenough was giving a contingent from 
Germany an explanation of the wiring processes. John had had some 
German in his education, and chose to use some German words with this 
group. In describing the process, he was explaining that young women had 
been hired to do the sensing wiring. He used the word “liebfrau” to 
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describe the women. He meant to connote young woman, but the word 
also implies virgin. After the tour, the Germans spent much of their time 
trying to determine how the liebfraus were selected. 

In parallel with the development of practical cores, their fabrica¬ 
tion into a random-access, high-speed core memory was being overseen by 
Forrester’s right-hand man, William N. Papian. In order to raise confi¬ 
dence in the core memory, a computer called the Memory Test Computer 
was built around the cores to test them. The Memory Test Computer was, 
in fact, the first computer to have a high-speed core memory, and it was 
also Kenneth H. Olsen’s (founder of Digital Equipment Corporation) first 
computer. The Memory Test Computer was used for several years after its 
testing of the core memory for data reduction and for testing SAGE 
peripherals. 

The core memory was an immediate success when installed in 
August 1953 (over one weekend) in the Whirlwind system. It doubled the 
operating speed and quadrupled the input data rate. Maintenance time was 
reduced from four hours a day to two hours a week, and the mean-time-to- 
failure was increased from two hours to two weeks. It also freed the people 
in the tube shop from working on the cathode ray tube memory for work on 
the needed operational displays. 



CHAPTER 3 


THE DIGITAL COMPUTER LABORATORY 
JOINS LINCOLN LABORATORY 


As work on Whirlwind was progressing in the late forties and 
into 1950, the Air Force was acting on the recommendations of the Valley 
Committee to establish a laboratory for research and development on air 
defense matters, and to carry out an interim study of the air defense 
problem. The short-term study, Project Charles, produced a report in 
1951. Meanwhile, MIT was planning the permanent laboratory, which 
was to be funded by the federal government but staffed and run by MIT. 
The laboratory would be built on federal property in Lexington, Massa¬ 
chusetts, next to Hanscom Field. Initially called Project Lincoln, the 
laboratory began operating in temporary quarters in Cambridge in July, 
1951. When the first buildings in Lexington were completed in 1952, it 
was officially renamed Lincoln Laboratory. The laboratory was headed by 
Wheeler Loomis for a time and then was turned over to A1 Hill, who had 
been the head of the Research Laboratory of Electronics. 

In the course of our work on Whirlwind, the team at the Digital 
Computer Laboratory had become very closely involved with Lincoln. In 
the summer of 1951, those of us in the Digital Computer Laboratory who 
were involved in applying Whirlwind to the air defense problem joined 
Lincoln’s newly established Division 6, Digital Computer, headed by 
Forrester. We remained in Cambridge for a couple of years but eventually 
moved out to Lexington. 

With its DCL identity, Division 6 was unlike the rest of the 
divisions at Lincoln. The DCL still continued its Cambridge existence 
under Forrester with its responsibilities for supporting the math group and 
other groups at MIT, and for operating Whirlwind. DCL/Division 6 had its 
own service organizations: its own publications, mailroom, and adminis¬ 
trative support. The justification for these organizational deviances was 
that Division 6 had some obligation to maintain the level of services to 
which it had become accustomed as the independent DCL, and these 
services could not be expected if it were totally integrated into the Lincoln 
Laboratory framework. 
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The other division of Lincoln Laboratory most directly con¬ 
nected with the air defense job was Division 2. Division 2, headed by 
George Valley, concentrated on radar and communications. Valley, a radar 
expert, had been a senior member of the Radiation Laboratory staff during 
the war and was one of the principal editors of the famed “Rad Lab” series 
of technical books. He had also been the chief man on ADSEC (Air 
Defense Systems Engineering Committee), where his work was primarily 
responsible for initiating the air defense upgrading. Valley had participated 
in Project Charles, and it was largely due to his and Forrester’s efforts that 
the concept of the air defense system we were working on was chosen by 
the Air Force. Valley was also Dr. Hill’s assistant director at Lincoln. 
Their names, Hill and Valley, were prophetic: as I would discover, they 
were miles apart in their approaches to management. 

Valley was dedicated to doing something for air defense in the 
relatively near future. Hill, on the other hand, was interested in the longer 
view and felt that the work Valley was doing was not as revolutionary in 
approach as the problem demanded. In 1952, in order to eliminate this 
difference of opinion, a second group was formed under Jerrold R. Zacha- 
rias of MIT. The findings of this group, called the Summer Study, illumi¬ 
nated what Zacharias considered to be a better approach than that backed 
by Valley and other interested scientists. Valley found that this version 
worked against the approach he was trying to take. This led to differences 
of opinion about important management decisions, and for a long time 
Valley found himself faced with internal Lincoln opposition. 



CHAPTER 4 


CONTRIBUTIONS OF AIR FORCE 
CAMBRIDGE RESEARCH CENTER 


When ADSEC was given the task of reviewing the U.S. air 
defense situation, it was also given administrative and technical support 
from the Air Force Cambridge Research Center (AFCRC). Most of the 
technical contributions were related to the work being done by AFCRC’s 
Relay Systems Laboratory on relay techniques for remoting radar PPI 
pictures. This pioneering work, headed by John V. (Jack) Harrington, 
would eventually lead to the development of automatic radar data network¬ 
ing. A good deal of this work took place in the late 1940s, before I was a 
part of MIT. My first encounter with it would come when I participated in 
meetings with Harrington’s group some years later, when we were pinning 
down design alternatives for cross-telling and surveillance reporting. 

The Relay Systems Laboratory was led by Jack Harrington, a 
soft-spoken, strong-minded Irishman, and his associates, Ernest W. 
Bivans and Paul Rosen. Bivans was a prickly, argumentative person who 
was very competitive and who had Harrington’s confidence. Harrington 
himself was a researcher who liked to prove the feasibility of his theoreti¬ 
cal designs, but he was not interested in the business of designing and 
packaging for field use, and had Bivans and Rosen participate in carrying 
out those functions. I found Rosen to be a likeable, entertaining raconteur, 
full of stories about the workings of bureaucracies, and especially about 
his experiences in the Navy during World War II. Through a series of 
bureaucratic blunders to which he fell victim, Rosen started as an officer 
candidate, but somewhere during the course of his service, he was classi¬ 
fied “illiterate.” In fact, he had been attending Tufts University and was in 
the Navy’s college training and midshipmens school programs, as well as 
electronic technicians school. Nonetheless, they made him a stevedore. 
He was never able to straighten out the error, and spent much of his time in 
the Navy on the loading docks in the islands of the Pacific. 

The efforts of Harrington’s lab in the late 1940s were centered on 
the completion of a microwave relay system that had been started during 
the war by the MIT Radiation Laboratory. The Relay Systems Laboratory 
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had taken on the problem of remoting radar PPI pictures — that is, 
automatically relaying the pictures and data over long distances to some 
central location remote from the radar which generated them. Two 
approaches were taken to the problem. 

The first approach was to use microwave as the relay method. 
The microwave relay system transmitted radar video signals that could be 
reconstructed and displayed at the receiving end. Experiments were set up 
using the Microwave Early Warning (MEW) radar at Hanscom Field to 
send signals to AFCRC in Cambridge some 20 miles away. The system 
worked very well, although it was costly and required several megahertz of 
bandwidth to transmit the unprocessed video. 

The second approach was the result of attempts to create a more 
efficient method of accomplishing the same objective, and was known as 
Digital Radar Relay, or DRR. DRR took advantage of the fact that the 
information content of the desired video signals was quite low: out of the 
entire radar picture, only a few blips were of interest, since only a few 
would represent aircraft while the rest would represent ground clutter and 
other noise. To automatically identify the aircraft returns from the entire 
field of returns, a detector was employed to integrate signal returns from 
pulses within the radar’s beamwidth. When enough energy had been 
returned at a given range to pass a certain threshold, the signal could be 
identified as an aircraft. 

Once the targets had been detected, their locations (range and 
azimuth coordinates, R, 6 ) could be transmitted in binary digital form. 
This reduction in bandwidth allowed the microwave circuit to be replaced 
by telephone lines as the means of transmission. A device was invented to 
convert the blips into R, 6 coordinates in binary form, and a modem was 
constructed to impress these digital signals onto the phone line. The 
information was transmitted to a remote location at 1300 bits per second, 
and demodulated. 

The DRR system was demonstrated successfully over a phone 
line from the MEW radar at Hanscom Field to CRC in Cambridge some¬ 
time in 1949 — and automatic detection of radar targets had been 
achieved. A year later, ADSEC was to use DRR in the first radar tracking 
experiments, in which the MEW radar, equipped with DRR, would trans¬ 
mit radar target data in real time to Whirlwind in Cambridge, where digital 
track-while-scan functions were performed. The work at the Relay Sys¬ 
tems Laboratory had been the basis of ADSEC’s confidence in the 
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feasibility of automating the detection and cross-telling requirements in 
their system concept, and also led to the transfer of most of the people in 
the Relay Laboratory to Lincoln. Jack Harrington’s group left the govern¬ 
ment laboratory and joined us in the air defense effort as Group 24, Data 
Transmission, in George Valley’s Division 2. 

At Lincoln, the DRR experiments were continued, and in addi¬ 
tion work on a so-called slowed-down video (SDV) system was initiated. 
SDV, a variation of DRR, divided the coverage area of short-range radars 
into a large number of wedge-shaped boxes, the number bounded by the 
range resolution required and the angular resolution that one could achieve 
with the radar antenna. If there were signal returns of a certain magnitude 
in a box, it would be called a target, and sent as a one (1) on a telephone 
signal stream synchronized with the radar pulses and angular position of 
the radar. SDV was inexpensive and effective, and was produced as the 
FST-1 processor by the Lewyt Corporation. Its major disadvantage, how¬ 
ever, was that its azimuthal accuracy was inherently poor. While it was 
appropriate for gap-filler radars, it was too inaccurate for the long-range 
radars. 

These inadequacies led to the next level of enhancement of DRR 
— the Fine Grain Data (FGD) system, produced later by the Burroughs 
Corporation as the FST-2. Its major improvement over its predecessors 
was better resolution, attained by a beam-splitting technique. This tech¬ 
nique depended on the fact that as a radar beam rotates the pulse rate is high 
enough so that it receives a number of returns, on the order of 10, from a 
single aircraft. The beam splitter was able to determine the center of the 
beam after it had swept across the target. Utilizing this device, it was 
possible to greatly increase the angular accuracy of the target location. The 
Fine Grain Data system also included automatic control and transmission 
of height finding signals, and control of beacon data from friendly aircraft. 

Further FGD improvements included an enhanced data transmis¬ 
sion system for telephone lines. Jack Harrington and Paul Rosen held the 
patent to this improvement, which allowed for an increase in data rate from 
600 bits per second to 1300 and later 1750. As contrasted to schemes that 
used single sideband transmission, where the carrier must be added for 
demodulation and synchronization, they transmitted part of the carrier 
frequency, thereby sending the signal along with its own timing. The 
system was the foundation of what became Bell Telephone’s A-l Data 
Service. 
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In those days, I did not know Jack Harrington too well but would 
get to know him better in the process of the SAGE computer design and 
specification of the communications cross-tell system. I remember him as 
being the type of person who protected his people. He was basically good- 
natured, had a wry sense of humor, and was enjoyable to talk with. 
Somehow, he did not seem to open his mouth when he talked. With the 
loquacious Bivans acting as his front man, Jack reminded me of a ventrilo¬ 
quist who moved his lips only when necessary to emphasize the authority 
of his pronouncements. 

With Whirlwind having the potential to process data in real time, 
and with Group 24’s data transmission schemes successfully tested, an 
experimental air defense system could be set up. 
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CHAPTER 5 


THE CAPE COD SYSTEM 


By early 1952, Lincoln management decided that the Whirl¬ 
wind computer was operating well enough so that it could be used as part 
of Lincoln Laboratory’s experimental air defense system. Called the Cape 
Cod System, the experimental network consisted of a direction center at 
the Barta Building in Cambridge, an experimental long-range radar at the 
tip of Cape Cod in South Truro, and a number of short-range radars called 
“gap fillers” at various locations around New England. The direction 
center was equipped with UHF ground-to-air communications. For pur¬ 
poses of creating a realistic test of the system, aircraft were supplied by the 
Air Research and Development Command and by the Air Defense Com¬ 
mand. The design of the Cape Cod System was headed by C. Robert 
Wieser of Division 6. 

It was determined early that the operational computer program 
for the Cape Cod System would require on the order of 20,000 instruc¬ 
tions. Whirlwind’s electrostatic storage tube memory could only accom¬ 
modate 2,048 words at a time. Thus, it was necessary to arrange for the 
storage of that operating program, and its efficient movement into and out 
of the high-speed memory at the appropriate time. To facilitate this move¬ 
ment, it was decided to add two magnetic drum memories to Whirlwind: 
one to act as an intermediate storage primarily for the core computer 
programs, and another magnetic drum to act as a buffer to record input 
from phone lines. As the central computer needed the data, it could select 
it from the appropriate head on the drum. 

Although the need for high-speed memory presented the greatest 
challenge and the magnetic core memory would represent the greatest 
innovation in meeting that challenge, there were several other memories in 
Whirlwind. There was a test memory consisting of 32 registers of toggle 
switch read-only memory which stored the start-up routines. Five addi¬ 
tional registers were electronic vacuum tube (flip-flop) registers which 
could be interchanged with any of the 32 toggle switch registers. And in 
addition to the magnetic drum memories, there was also a tape memory for 
backup which stored the whole program including simulation, evaluation, 
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and diagnostic routines. Additionally, the tape was used to record opera¬ 
tional data, so that analysts could diagnose the entire operation or use the 
data for whatever they needed. With Raytheon, the Whirlwind team 
developed a memory capacity of 125,000 words per tape. 

In 1950, as soon as the Whirlwind computer was able to perform, 
the experimental Microwave Early Warning (MEW) radar located at 
Hanscom Field in Bedford was connected using Jack Harrington’s equip¬ 
ment and commercial phone lines to Whirlwind in Cambridge, and the 
first tracking programs were developed. By 1952, the Cape Cod team had 
demonstrated the ability of the computer to track and control aircraft in 
small numbers. 

The man in charge of computer programming for these feasibil¬ 
ity experiments was David R. Israel. Dave had joined the Digital Com¬ 
puter Laboratory in 1949, and he was one of the first people in the Cape 
Cod design group. In 1949, the DCL was looking at alternative uses of 
Whirlwind for real-time applications, and was awarded a contract by the 
Air Force to study its application to military air traffic control. Dave joined 
DCL in 1949 and did his thesis at DCL on civilian air traffic control, and 
he investigated the uses of Whirlwind in ship and harbor control. When the 
DCL became involved in air defense, he began programming Whirlwind 
for the feasibility experiments — a remote display experiment, a track- 
while-scan experiment, and the first interception using the MEW and 
DRR. At that time, there were no formal computer programming courses, 
but attempts were made at it in which Jay Forrester and Gordon Welchman 
participated. Both Jay and Gordon had to learn the process from scratch. 

The first single-thread system (that is, the first system that con¬ 
tained both tracking and weapons control), was programmed using a 256- 
register, high-speed cathode ray storage tube. It was originally intended 
that the cathode ray storage tube have 1,028 registers, but because of the 
migration of the charges on the surface of the insulator used, it was felt that 
the tubes would be much more reliable operating at the lower register 
count, and so the track-while-scan and weapons direction program was 
first implemented in 256 registers. All other programming support func¬ 
tions, such as the assembler and checker, required too much storage to fit 
into 256 registers. Since there were no utility aids, the programming had to 
be done in machine code. The translation of programs into machine code 
had to be a direct process in which all of the manipulations and translations 
took place in the programmer’s head. 
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Dave was a tough negotiator, and I would get to know him years 
later when we were settling on the SAGE computer’s order code. He 
played a key role in the development of the early programs for operational 
surveillance, initiation, identification, weapons direction, and weapons 
management. He also spent a good deal of time on the operational design 
of the display console used in the Cape Cod System. 

For the Cape Cod “53” design (so called because it was expected 
to be operational in 1953), the programming responsibility was divided up 
between Israel and Robert Walquist. Bob was a hulking 6'4", 200 lb. man 
with a jutting jaw and a head that sat atop a bull neck — physically, he was 
as imposing as an Easter Island monolith. Because of his size and general 
bulldozing characteristics, he had earned the nickname “Moose.” Moose 
added a great deal of color to the Cape Cod design group. He was bright, 
energetic, and extremely argumentative. He was given the track-while- 
scan functions, and Dave all the others. Walquist would speak his mind 
clearly and argued with whomever he thought needed straightening out. 
On one occasion, when George Valley visited the laboratory to witness one 
of the demonstrations, Walquist got into an argument with Valley in front 
of Forrester and the other group leaders. Valley remarked that Jay should 
promote Walquist so that he would be at a level appropriate to Valley’s 
rank. After the 53 program was completed, Walquist decided to join TRW, 
where he later became a vice president. 

The Cape Cod System was intended to demonstrate the opera¬ 
tions that were to be executed for field use; in particular, the surveillance 
function and weapons control function. Both of these functions required 
information on the position of hostile and friendly aircraft. Some scheme 
wherein all of the operators in the Barta Building direction center operated 
from the same positional data base became a requirement. The scheme that 
was adopted depended upon the idea that all data of interest would origi¬ 
nate at the radar or ground observer sites. This data was transmitted to the 
direction center in angular coordinates, where it was translated into Carte¬ 
sian coordinates, and where the position of the radar that picked up the data 
was added. With this scheme, each piece of radar data had an X-Y position 
in a common coordinate system, and data from overlapping radars could 
be combined. All of the operating stations were equipped with consoles 
that had cathode ray tube PPI-type displays. During the course of the 
operating cycle, this data was presented to an X-Y register which deflected 
the beam to the proper coordinates on all of the operating positions. It was 
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then necessary to associate these positions with other information, such as 
track number, identification, altitude, speed, armament, and whatever 
other data seemed to be necessary for the execution of the functions at that 
position. Making this association was one of the first applications of the 
light gun, for which Bob Everett holds the patent. As the data with the 
coordinates of interest was presented on the cathode ray tube to the 
operator, he would place the light gun, which contained a photoelectric 
cell, over the spot where he expected the data to appear. He would then 
press a trigger, and when the screen was illuminated at that position, a 
signal was sent to the computer which told the computer that this was the 
data of interest which should be associated with this position. 

In order not to clog the information channels from the radars, 
a device called a video mapper (which was really a filter) was added be¬ 
tween each radar input channel and the computer. This mapper was a plan- 
position display with a photocell over the whole display. Returns such as 
those one would receive from fixed objects in their radar picture were 
covered with opaque material so that when this data appeared, it did not 
activate the photocell and was rejected before it got into the main operating 
system. 

By the time the Cape Cod System was finished, it had about 30 
operational positions with appropriate displays. Not all the data could be 
displayed on the face of this cathode ray tube, so the Whirlwind group 
created an auxiliary tabular display, and data associated with a particular 
track could be shown alphanumerically on the display. This eliminated the 
need for a large number of data symbols on the PPI itself. This need for 
symbols on the face of the display tube eventually led to the selection of the 
Charactron tube which would be used in SAGE. 

The Cape Cod System was in essence a model of the large-scale 
air defense system. It was used in exercises which included Strategic Air 
Command (SAC) bombers playing the role of hostiles, and the Air 
Defense Command and Air Research and Development Command inter¬ 
ceptors playing a friendly role. Before the Experimental SAGE Sector 
(ESS) which grew out of the Cape Cod System was finished, 5,000 or so 
sorties had been flown against the system to test the whole system as well 
as its component parts. 

The Lincoln air defense system was not the only system being 
considered by the Air Force. In fact, the Air Defense Command, through 
its representative, Colonel Oscar T. “Tom” Halley, was placing its efforts 
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in support of a system concept proposed in the early fifties by the Willow 
Run Laboratory of the University of Michigan. This concept favored 
manual tracking aided by an analog computer at the radar sites and 
coordination at the direction centers. It was an offshoot of Michigan’s 
BOMARC project, a ground-to-air missile under development for the Air 
Force. The Willow Run proponents stressed the superior discriminating 
power of the human eye in distinguishing between noise and radar returns 
from aircraft. In their system, the track was followed by a tracking ball- 
operated cursor. When the cursor was placed over the data on the screen, a 
calculation was made which predicted the next expected appearance of the 
radar return. The Willow Run system did not have the Lincoln advantage 
of overlap coverage, which increased the amount of data and reduced the 
cross-telling, handover, and backup problems by centralizing the surveil¬ 
lance function. It also suffered from the fact that there was no experimental 
gear that could provide proof-of-concept and confidence in its eventual 
operation. Thus, Michigan’s paper design faced the competition of a live 
system in MIT’s early Whirlwind MEW demonstrations. The ultimate 
decision favoring the Lincoln approach was based partly on this fact and 
partly on the tactics used by Dr. James R. Killian, who was president of 
MIT at the time. Killian let it be known to the Air Force that he knew the 
Willow Run system was being favored by the Air Defense Command. He 
offered to withdraw from the competition if it were the Defense Depart¬ 
ment’s intention to go with the Michigan system, saying in effect he didn’t 
want to waste his time playing second fiddle to Michigan if the Air Force 
had indeed made that decision, and to please let him know. This put the 
prestige of MIT in competition with the University of Michigan. 

Killian, in effect, had finessed the situation, but would not have 
succeeded without the senior military’s confidence in George Valley, a 
seasoned and formidable infighter who argued the technical merits compe¬ 
tently and who had the military R&D community in his camp. In the early 
days of the program, George was very helpful to the Digital Computer Lab 
in the selling of Whirlwind to the Air Force. He believed, as did Jay 
Forrester, that real, live demonstrations of the parts of the system were 
essential in judging the quality of the devices that were chosen to be part of 
it. He also believed that one must choose some systems on the basis of their 
demonstrability, sacrificing idealized projected performance. It was this 
belief that corresponded to Jay’s belief in the value of the practical demon¬ 
stration. Having something concrete to demonstrate was the cornerstone of 
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their marketing strategy, and they cooperated in demonstrations when 
Valley needed backup for the things he was trying to promote. Throughout 
the history of the SAGE system, people in Washington would be given 
practical demonstrations of the workings of subsystems and systems. 

You could almost say that Whirlwind liked George Valley. 
Whenever George would ask us to get Whirlwind ready for a demonstra¬ 
tion to people he was trying to “sell,” the machine would invariably be 
down. But even on short notice, the Whirlwind people would patch things 
together, and it would perform flawlessly for the duration of the demon¬ 
stration, only to crash as soon as George and his party left. 

One incident stands out during the period when the Air Force 
was trying to make up its mind about Lincoln Laboratory, and when MIT’s 
ability to carry out the project came into question. Bell Laboratories was 
asked to evaluate the Lincoln plan, and a review group, headed by Mervin 
J. Kelly, president of Bell Labs, was formed. They were critical of the 
approach being taken by Lincoln, and considerable tension was generated 
between the two organizations, with Bell Labs criticizing and Lincoln 
defending the Lincoln approach. MIT had recommended that Bell Labs do 
the systems engineering for the air defense system. Bell refused to take 
responsibility for the design, but agreed to help with the administration of 
its execution. The tension was great enough so that the Bell Laboratories 
and MIT management thought it necessary to hold a peacekeeping or fence 
mending get-together, which took the form of a banquet for the MIT and 
Bell Labs people associated with the evaluation. Conciliatory speeches 
were made, and pledges of mutual respect and friendship formed the basis 
of these talks. Each speaker de-emphasized the differences and empha¬ 
sized the common ground. It was an organizational love-fest. When it 
came time for A1 Hill to speak, he got up and said, “Our computer can beat 
your computer,” and sat down. This put a perfect cap on the proceedings. 
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CHAPTER 6 


WHIRLWIND II 


Mfter Whirlwind was operating successfully and the feasibility 
experiments were done, the design of the operational air defense system 
had to be initiated, and this was paced by the design and development of its 
computer. It had become clear to those who had participated in the Valley 
Committee and in the Charles Study that Whirlwind was more of a 
brassboard than a prototype of the computer that would be used in the air 
defense system. To turn the ideas and inventions developed on Whirlwind 
into a reproducible, maintainable operating machine would require the 
participation of an industrial contractor. This follow-on computer became 
known in the early fifties as Whirlwind II. 

Within Lincoln, there were many alternative concepts of how 
this computer would be employed in a system. The most popular concept 
consisted of three computers in different locations, any two of which could 
carry the whole air defense load while the other one maintained itself, 
corrected errors or expanded the capacity of the machines carrying the 
operations. This and many other different combinations of computer 
arrangements were eventually discarded in favor of a scheme of duplex 
computers, where two identical computers at the same location shared the 
same operational data base — one operating the air defense business of a 
sector, with the other checking itself and checking the operating machine. 
When a fault occurred, the standby computer could quickly take up the 
operational load, while the failed operating computer could turn toward 
diagnosing its own difficulty. Replacement components could then be 
substituted to correct the problem. 

The most important goal established for Whirlwind II was that 
there should be only a few hours a year of unavailability of the operational 
system. The Whirlwind II team at Division 6 thought this was possible, 
extrapolating from the experience on the Cape Cod System. The speed and 
capacity of the projected machine were increased by a decision to employ a 
dual arithmetic element, one to work on the X portion of the position 
calculation, and one to work on the Y portion, since so much of the 
processing time involved data in Cartesian coordinates. The capacity of 
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the machine was also increased by providing a display drum which 
relieved the central computer from the job of refreshing the displays. 

Most of the design choices faced by the Whirlwind II group 
involved the tradeoff among the number of tracks that could be processed, 
the number of interceptors that could be employed simultaneously, and the 
availability criteria. The Whirlwind II group had been set up as Group 62 
in 1951 under Norm Taylor to deal with all hardware design questions, 
including whether transistors were ready for large-scale employment (they 
were not) and whether the magnetic core memory was ready for manufac¬ 
ture (it was). 

The SAGE system was to be the first system to use computer-to- 
computer communications. There would be a forward-telling link to carry 
data from the direction centers to the combat center as well as from each of 
the radars to two or more of the direction centers. In addition, there were 
cross-tell links between direction centers. This networking part of the 
design was dominated by Ronald Enticknap, a former R&D exchange 
officer and RAF squadron leader from Great Britain, who had been a 
junior member of the RAF delegation to Project Charles. 

In order to accommodate the volume of traffic among sensors 
and radars, several multiplexing devices were required. In addition, the 
phone lines had to be engineered to reduce phase distortion caused by the 
inductive characteristics of the lines themselves, so each line had to be 
engineered to square up the pulses used in the communication. Each line 
was duplicated for backup reasons. The modulator/demodulator units 
were an extension of a design by Harrington’s group. Paul Rosen had the 
responsibility for bringing these units to a point where they could be used 
in the Cape Cod System. Once he had the experimental modems working 
in the field, Ronnie Enticknap took over the completion of the job and the 
negotiations with AT&T. 

Ronnie was partially responsible for the “quick fix” system, 
aimed at providing immediate upgrading of the Manual System by substi¬ 
tuting an automatic display surveillance picture for the handwritten, 
grease-pencil updates. The quick fix system was to employ a Polaroid fast- 
developing camera/projection system that took information from the vari¬ 
ous PPI scopes and projected it in overlay fashion onto a horizontal, 
table-top like plexiglass board. Operators sitting around the periphery of 
the board were to see a picture which was more comprehensive than that 
which could be seen on individual PPIs. I never knew why it was felt that 
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the quick fix system was superior to the existing one. Since it was never 
deployed, I suppose that people eventually found it actually had minimum 
capability and no growth potential. 

I first met Ronnie on a tour of the Truro, Cape Cod, site. Part of 
his standard tour included the witnessing of a simulated air strike. The 
thing that stands out in my mind about the simulation demonstration was 
the orientation, given by Robert Davis and Anne Smalley. Anne was 
squarely built, had a severe short haircut and usually wore mannish suits. 
She gave the introduction in a baritone voice. Davis, her teammate, was 
skinny and nervous, and spoke in a high-pitched voice. The North Truro 
operational site was a typical GCI site in the system, with the big plex¬ 
iglass board in front, and bleacher-like working areas with remote PPIs to 
the various functional officers, the two main functions being surveillance 
and weapons direction. When we arrived in this room for the demonstra¬ 
tion, it was all business. There was a steady background noise of electric 
motors and the crackling of ground-air radio. A faint blue light dominated 
the darkened room. When we entered, there were a few blips on the big 
screen identified as “friendlies.” Davis was visibly nervous about whether 
they could demonstrate the system without any hostile blips. Enticknap 
wasn’t sure that they could give the demonstration, so he started to buy 
time by explaining who did what. We had almost given up seeing the 
simulated intercept and were starting to leave when a new aircraft was 
grease-penciled onto the screen. Almost simultaneously Davis’s high 
voice shattered the businesslike atmosphere of the room as he shrilled, 
“Oh, Ronnie — hostiles!” The room suddenly lost its authoritative 
feeling. 
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CHAPTER 7 


ASSIGNMENT TO GROUP 62 


When I joined DCL in mid 1951, I was assigned to work with 
Norm Taylor in Group 62. Taylor had come to the laboratory in the late 
1940s from Western Electric. As well as having responsibility for Whirl¬ 
wind II, he was DCL’s chief hardware systems engineer, and was one of 
the few at the laboratory who had had industrial experience. To Taylor’s 
credit was the design and construction of the five-digit multiplier. 

Norm was a good engineering manager, with an instinct for 
analyzing any given situation. He had an intuitive feeling for structuring 
problems so that they could be studied. He had a way of synthesizing 
opinions and projections into an overall direction for the group. He never 
pulled rank, and he always brought people in on problems when he could. 
You could get the idea that he did virtually everything, and as a matter of 
fact, he did contribute directly to most of the design judgments that were 
made. Norm was older than most of us, and we had many conversations 
with him about what our next career steps should be. On the job he 
preferred to work one-on-one, and he and I worked well together. Norm 
was a computer system gadfly. He had an enormous capacity for optimism 
and much of his communication to the staff was in the form of pep-talks, 
which he would give whenever things seemed to be coming apart. This 
optimism and his way of dealing with it came to be known as “Taylor’s 
sunshine pump,” which could be turned on whenever one of the staff 
needed it. 

The first task Norm assigned me to was to determine whether 
transistors, which had just recently been invented, should be a candidate 
for a major Whirlwind II component. The only transistors that existed at 
that time were point contact germanium transistors which were scrounged 
during visits to Bell Laboratories. At that time, there was no commercial 
manufacturer or supplier of transistors but there were experimental models 
being developed by various companies — Bell Labs, RCA, GE, Philco, 
and others. Since transistors were quite different from the vacuum tube 
circuitry that I was used to — solid state, low voltages, holes instead of 
electron flow and the like — we first had to learn a whole new vocabulary 
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and way of thinking about circuits. We had to learn to design and build 
flip-flops and various kinds of gate circuits. Then we tested the transistors 
for speed of operations and reliability, and we tried to determine how they 
might be applied to an arithmetic element. Through my research and with 
the assistance of other people at MIT, I came to the conclusion that the 
transistor speed characteristics would allow us to achieve very high rise 
times and very high speeds, but the reliability and availability of the point 
contact transistors would be a matter of concern. Eventually this research 
led to my master’s thesis topic, “A High-Speed Counter Employing Transis¬ 
tors,” which involved actually building and testing a transistor counter. 
We did not have enough transistors to build anything more complicated. 

I built the transistor counter using the Digital Computer Labora¬ 
tory’s famous tool kit which was issued to all new staff. The tool kit was a 
sort of symbol of the hands-on character of the Computer Laboratory’s 
work. It contained such basics as a soldering iron, diagonal cutters, 
needlenose pliers, and a variety of wrenches. My first year there, I used it 
often, but after that, it found a home under my desk where it served both as 
a footrest and as a constant reminder of its lack of use. As time went on I 
found various tools missing from the kit. Often, I felt guilty about not 
turning it in; but at the same time, I didn’t want to because I was unable to 
explain what had happened to the missing tools. This unretumed and semi- 
depleted tool kit lay on my conscience for four or five years until I finally 
decided to turn it in and take the consequences. It wasn’t until a while after 
I’d turned it in that I learned that tool kits had been declared as surplus and 
designated as expendables by the laboratory — and that the people in the 
tool room had laid claim to the returned tools in my kit. 

Some months after I joined the Digital Computer Laboratory, I 
finally saw Bob Everett. I remember looking into a room in which several 
people had gathered and, sitting in a lotus position on the table was a 
slightly chubby, pleasant looking man in animated conversation with the 
others. I listened for a while and it became clear that this soft-spoken man 
was held in high regard by the people with whom he was talking. When I 
told Taylor about it, he said it must have been Bob Everett. What clinched 
the identification was my mentioning that in the midst of conversation, the 
man would put his head back and whistle while he thought. It was at about 
that time I found out that Everett was the real inside man at the laboratory, 
that he had been in charge of the block diagrams for the Whirlwind I 
machine, and that he had the complete confidence of Forrester. 
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Professor Sam Caldwell was my thesis advisor. Caldwell was a 
helpful advisor and my personal relationship with him was good, but to 
outside appearances he was not a happy man. He talked freely about his 
belief that he had not received the credit he deserved for the development 
of the differential analyzer. He also seemed very negative about what was 
going on at Whirlwind. He seemed to feel that some of the people at the 
Digital Computer Laboratory were against him. I never did understand his 
negativeness, but presumed it could have been due to a serious physical 
ailment he suffered at the time. 

I also encountered criticism of the Digital Computer Laboratory 
from another unexpected source. In the course I took from Caldwell on 
logical design and Boolean algebra, we had used a book that had been 
produced by the Harvard Computer Laboratory, under Dr. Howard Aiken. 
During my final semester (spring 1952), I thought it would be profitable to 
take a course on digital computers from Aiken, who had developed the 
Harvard Mark I selective sequence calculator. I went to visit Aiken to 
discuss my taking his course. We met in a conference room that he chose to 
use for the interview. I did not see his office, which was alleged to have his 
desk set up on a platform, so that his visitors were forced to look up to him. 
He spent most of our time criticizing what was going on at the Digital 
Computer Laboratory and at MIT, and it became apparent that he was not 
enthusiastic about my signing up. The gist of Aiken’s criticism of Whirl¬ 
wind seemed to center on his estimate of the reliability of vacuum tubes 
and the large number of vacuum tubes in the system. He used these 
numbers to show that the tube reliability was such that the mean-time-to- 
failure precluded any useful time for the machine; that is, the failure rate 
would be so high that the machine would not run long enough to do any 
useful work, and besides, even if it did work, there weren’t any problems 
requiring the projected capacity of the machine. I understood from discus¬ 
sions with Taylor, Forrester, and Everett that he had used the same 
arguments with them. 

The work that was done by the people at MIT, including the work 
that I did, convinced Norm Taylor and his superiors that transistors were 
too early in their development to be applied to a production machine in the 
short term. As my thesis work came to an end, I had become more and 
more aware of the other project activities within Group 62. Taylor’s 
Whirlwind II Group 62 was set up in the Whittemore Building on Albany 
Street in Cambridge, a stone’s throw from the Barta Building where the 
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Whirlwind I was being finished. The Whittemore Building had been a shoe 
polish factory and in the early days there were still signs of shoe polish on 
the walls and on the floors, as well as a steam-powered engine with a ten- 
foot flywheel in the center of the building. 

I graduated in June 1952, just a few days after our third child was 
bom. Some time earlier I had been looking for a full-time job. Staying on 
where I was seemed to be a good idea because by this time I had estab¬ 
lished a reasonably good reputation with Taylor, Everett, and Forrester. I 
remember Everett offering me some small monthly amount to join the 
laboratory. I was surprised that the offer was so low, and I pointed out to 
Everett that I had been making almost as much before I decided to return to 
college and to study engineering (I had studied architecture before the 
war). I learned later that Everett was surprised by my attitude since his own 
salary wasn’t much greater than what he offered me. But I liked the people, 
I was establishing a reasonable reputation in the laboratory, and it was 
clear that the air defense program was going to be a significant one. I was 
learning a lot about digital computers and I was contributing, so I took the 
job. 

My first assignment on a full-time basis was with Dave Brown, 
who had been responsible for the control subsystem in Whirlwind I. He 
had also been responsible for some tube reliability studies. I had just 
finished the course on logical design and Boolean algebra with Caldwell, 
and Dave didn’t know what to make of me. I tried to apply Boolean algebra 
to the problems that cropped up in the logical design of Whirlwind II, and I 
covered sheets of paper with equations trying to make the algebra work. 
Although I could describe mathematically what logical design existed, it 
didn’t help much in the design process. Dave Brown was shy, but it was 
clear that he didn’t think much of the product that came from all of my 
algebraic manipulations. I finally dropped the project. 

Dave was a continuous cigar smoker. I asked him once why he 
smoked so many cigars, and he replied that when he went away to college, 
and he was lonely, he found that smoking a cigar reminded him of home 
and his father, and this tended to calm him down in times of stress. After 
that conversation, I would always pick up a cigar at any banquet where 
they were passed out and bring it back for Dave. 

I didn’t work very long with Dave. Shortly after I had been hired, 
he was assigned the task of overseeing the production of cores for the 
random access core memory, and I continued my work under Norm 
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Taylor. My experience with Group 62 gave me a broad base of pertinent 
computer component know-how which, in turn, opened doors to knowl¬ 
edge of other components and subsystems that were also part of the overall 
computer system. It was an excellent preparation for subsequent jobs 
assigned to me, among which was the design of the arithmetic element. 
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CHAPTER 8 


DEFINING THE WHIRLWIND II 
ARITHMETIC ELEMENT 


Mfter the transistor work was completed in early 1952, I was 
named section head with the responsibility for defining the arithmetic 
elements for Whirlwind II. We began by looking at a cross-section of the 
computers that had been produced to date — the Whirlwind I, the SEAC, 
the Remington-Rand machines, the IBM 701 and others. We knew it was 
essential to the air defense problem to increase the number of radar tracks 
which could be processed within a certain time frame. In order to maxi¬ 
mize the tracks covered, it was essential to minimize the processing time, 
to the point at which the only limiting factor would be the read/write cycle 
of the high-speed core memory. We had some statistics on user programs 
for the air defense problem and realized that in the programming for the 
Whirlwind I computer, each of the operations in the instruction code could 
be executed within the high-speed memory cycle of the computer — except 
for multiply, which took up about 10% of the air defense program code, 
and divide, which was used much less frequently. Our task, then, was to 
minimize the time required for the multiply instruction, which would also 
benefit the divide instruction. Since multiplication involves a series of 
additions, we were led to the design of the fast adder. My section took 
charge of its design. It depended on a circuit which, when pulsed, propa¬ 
gated from number column to column as fast as it could be transmitted, 
automatically shifting the carry over one column. It was a new idea. We, in 
the arithmetic element group, along with our IBM counterparts who would 
join us later in this work, would be named as the inventors in 1954. Like 
most patents, the title didn’t seem to describe the work we were doing. The 
title of our patent was, “Digital Computer with Inherent Shift.” For one 
brief, shining moment, the Whirlwind II arithmetic element was the fastest 
in the free world. 

I found I was helped greatly in the design task by the experience I 
had had prior to coming to MIT — teaching in television trade school and, 
before that, as a chief electronic technician’s mate in the Navy with 
responsibility for a part of the electronic technician’s mates curriculum, 
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including teaching a course in special circuits, particularly pulse circuits. I 
was also familiar with radar and with direction centers as they were 
designed for the Navy (combat information centers), so, shortly thereafter, 
when the Digital Computer Laboratory was integrated into Lincoln Labo¬ 
ratory, and the air defense system became the central concern, I had the 
necessary background. A significant number of the staff of the Digital 
Computer Laboratory had backgrounds similar to mine: that is, they had 
learned about radar, communications, and radar direction finders in World 
War II. Most of them had also been in the Navy in the electronic techni¬ 
cian’s program, where the ideas of flip-flops, memory, pulse circuits and 
delay lines were familiar ground. I found out later that hiring people with a 
background in military electronics was a conscious policy that Everett and 
Forrester had adopted. 

While the recruiting philosophy of the DCL stressed hands-on 
problem solving at the expense of some of the theoretical niceties, most of 
the staff members had master’s degrees in engineering, including Jay and 
Bob. But there was always a vague, subconscious feeling that a greater 
number of Ph.D.’s would be helpful in counteracting some of the criticism 
from our government sponsors, and that it might eliminate some of their 
continual investigations. And so, we were all pleased when Jay was made 
an honorary Ph.D. by his alma mater, and there was a period during which 
the “Dr.” in his title was stressed. However, most of the people who were 
hired to fill the need for Ph.D.’s did not survive, because their more 
abstract work could not be applied effectively to what was essentially a 
large engineering project. Sometimes, people would assume that those of 
us who did not have Ph.D.’s did in fact have doctorates. This would 
happen occasionally at an event where we were mixing with known 
Ph.D.’s. If you were addressed as “Dr.” and were silent on the subject, 
those in the group who knew better would brand you as pretentious, but if 
you corrected the speaker, you were forced to tell him that you were not as 
well-educated as you appeared. The people who had honorary doctorates 
had a double problem of explaining that yes, they had a Ph.D., but that it 
was not a “real” Ph.D. However, if you had enough of them, it didn’t 
matter. 

Another source of trained electronics people was the Harvard/ 
MIT radar program, which was open to military people who had had 
degrees in engineering when they were inducted, especially degrees in 
electrical engineering. Typical of this was the case of Gus O’Brien, a 
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circuits engineer who became a great contributor to Whirlwind I. Gus went 
into the Army shortly after he graduated from the University of Maine. He 
went to officer’s training and then into the Harvard/MIT radar program. 
By the end of the war, he was a captain in the Army Signal Corps at Clark 
Field in the Philippines. He had written his professor at the University of 
Maine, telling him that he wanted to go to graduate school when he 
returned. His professor urged him to apply to MIT instead of Maine 
because of the opportunities open there. Gus was in the process of setting 
up a radio and radar maintenance school for Air Force communicators 
when he wrote to MIT. His resume was sent to Forrester, who expressed 
interest in having him join the research assistant’s program and coming to 
the lab. 

Gus had always been called John O’Brien, rather than Gus, until 
he interviewed with Forrester when he returned to the States. According to 
Gus, near the end of his interview, Forrester asked him what his middle 
name was. Gus told him it was Augustus. Forrester complained that he 
already had one John O’Brien in the laboratory, and that from now on he 
would be known as “Gus.” The name stuck even after the other John 
O’Brien left the laboratory. Gus O’Brien worked for Dave Brown on the 
development of the control system and the selected flip-flop. 
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CHAPTER 9 


JAY FORRESTER AND COMPANY 


I don’t remember exactly when I met Jay Forrester. I believe he 
was off working on Project Charles when I joined the Digital Computer 
Laboratory, but I was keenly aware of his presence because of the policies 
he had fostered in the DCL, one of which was the biweekly report. It was 
clear that Forrester believed in full communication among the people in 
the laboratory. Once every two weeks, everyone in the laboratory had to 
make a written report on what he had done and accomplished during the 
previous two weeks. All these reports were bound together and circulated. 
Through the biweekly report we could find out what everyone else was 
doing, and it also helped us to discipline ourselves by giving us an 
incentive to do something during that time period that was worth reporting. 

My office at the Digital Computer Laboratory was next to that of 
Forrester’s principal man on the core memory, Bill Papian. Papian was 
also in Group 62, and it was through this coincidence that I became even 
more aware of Forrester’s presence. Papian was working on the feasibility 
model of the random access magnetic core memory which Forrester had 
invented in response to the need for a reliable high-speed memory. Forres¬ 
ter’s invention replaced the unreliable electrostatic storage tubes with 
magnetic cores whose magnetic field could be switched and held by the 
hysteresis characteristics of the cores. 

What Papian was trying to prove was that a way could be found 
to string up magnetic cores so a single core could be reliably selected from 
the array and in the switching process would not interfere with the mag¬ 
netic orientation of other cores in the plane. Forrester, of course, was 
interested in Papian’s work, and they had many discussions which Papian 
would later relate to me. It seemed that Papian and Forrester were oppo¬ 
sites in temperament. Papian was a careful, thoughtful, sensitive engineer 
who saw his problems from every angle, and continually had arguments 
with himself about the best way to go. Forrester, in contrast, never seemed 
to have any doubts about anything. This, from what Papian told me, made 
for a very interesting working relationship. Not only did knowing Papian 
give me insights into Forrester, but I was also able to see from Papian’s 
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work what the read/write time would be in magnetic core memory, and I 
gained the confidence that the fast adder and multiplier my section was 
working on for Whirlwind II was desirable. 

I also met another contributor to core memory: Ken Olsen. Olsen 
was later to go on to found the Digital Equipment Corporation, which 
evolved from his work on the memory test computer he had developed to 
test out the Whirlwind core memory. Olsen didn’t fit my image of the 
successful entrepreneur. He came across as a happy, ebullient, practical 
man, almost evangelical about his work. He was a stout man, large head 
and shoulders, with a firm jaw, and very large teeth. 

Olsen always considered the whole design. He realized that the 
box the electronics was housed in, the switches that were used, and power 
supplies were as great a source of trouble as were the working elements, 
vacuum tubes, transistors, or whatever. When he talked about computers, 
he made them sound almost metaphysical. But, he was an engineer’s 
engineer — very pragmatic. 

Although Olsen had been assigned to design modular test equip¬ 
ment for use in the laboratory, he saw, in the task of testing the core 
memory, the potential for using these modules in building a general- 
purpose computer. The computer could test the core memory as well as be 
a usable machine itself, so he designed what would now be called a 
minicomputer. The memory test computer found ample use in its time in 
testing and demonstrating SAGE peripheral devices. It would also be used 
to do some of the data reduction on data generated in the testing of the 
prototype SAGE computer, the XD-1. 

The modular test equipment (out of which the memory test 
computer was partially built) was another example of how the Digital 
Computer Laboratory had committed itself to building standardized test 
equipment. The first commitment was made in 1948, when Forrester had 
assigned Harry Kenosian responsibility for coordinating the design and 
procurement of standarized test equipment that could be used to create 
logical networks which simulated the environment the tested element 
would face. 

Forrester had instituted other ways of communicating within the 
laboratory. On Friday afternoons, he invited a large number of his staff to 
his “teas.” At these affairs, his favorite cookies, which he purchased from 
a local bakery, would be brought in, and people would sit around eating 
cookies, drinking tea, and talking about anything that came to their minds. 


40 



Forrester oversaw this ritual, assuming a kind of fatherly stance, but even 
then he appeared to be cool, correct, and erect, and to those who didn’t 
know him well, unapproachable. In point of fact, he was quite approach¬ 
able and very interesting to talk with in person. Forrester had the reputa¬ 
tion for being extremely shy in the early days, but he disciplined himself 
by deliberately placing himself in situations where he would have to 
overcome shyness. 

Forrester was an idea-directed man. He believed in practical 
solutions to problems and tended to generalize from specifics that were 
arrived at through empirical means. He gave short shrift to fuzzy philo¬ 
sophical or unfounded theories or approaches which required esoteric 
mathematics as the basis for their proof. He was also a confident man — 
confident of himself and of his organization. When Whirlwind I was being 
criticized for not having enough influence from the mathematical commu¬ 
nity, his response was to the effect that he really didn’t need that kind of 
participation, but if the Navy wanted it, he would arrange for his own 
mathematicians and let them see if they could be of any help. Forrester 
never seemed to take criticism personally. He had the unusual ability to 
project the consequences of decisions on the overall program, and he was 
willing to fight for anything he believed in. 

Although I had not met Forrester when I joined the laboratory, I 
was aware that he had gone to the University of Nebraska, and that he was 
the son of a teacher-rancher who taught in a one-room schoolhouse. I felt a 
kinship with Jay, having shared the prairie growing up in the Depression — 
the dustbowl with its jackrabbit boom and its grasshopper scourge, and its 
loneliness. My first professional encounter with Jay was through the work 
my section did on the arithmetic element. I had derived a way of placing all 
existing arithmetic techniques in computers under development in rela¬ 
tionship to each other in terms of system reliability and speed. I treated 
system reliability as a function of the complexity of the circuits (number of 
components and individual component reliability), and speed was the 
speed at which they could do a standard multiply problem. Each of the 
arithmetic elements was given a weight based on these factors. (We 
designed an arithmetic element using each of the techniques we had 
observed.) The result of this analysis was a factor in the choice of standard 
circuits for Whirlwind II. 

The few conversations I had with Forrester before I started work 
on the arithmetic element were usually one-sided, with Jay expounding 
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on the various schemes that intrigued him, such as marginal checking. 
When we discussed the arithmetic element and the study my section had 
done comparing all the currently available techniques for making a multi¬ 
plier, he was impressed and immediately became interested. I think it was 
that as much as anything that brought me into contact with the broader 
concerns of the SAGE program. 
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CHAPTER 10 


SELECTION OF A COMPUTER CONTRACTOR 


I he idea of engaging a manufacturer to help with the design and 
engineering and to do the manufacturing of Whirlwind II was implicit in 
the nature of the R&D mission of Lincoln Laboratory. To achieve this end, 
a group consisting of Jay Forrester, head of Lincoln Division 6 and of the 
Digital Computer Laboratory; Bob Everett, associate director of Division 
6 and of the Computer Laboratory; Bob Wieser, leader of the Cape Cod 
System project; and Norm Taylor, head of Group 62 and chief engineer of 
Whirlwind II, was charged with the responsibility for finding the most 
appropriate computer manufacturer and designer to translate the progress 
made so far in the Cape Cod System into a design for the next generation 
transitional air defense system. This system was to become known as the 
Lincoln Transition System, and in 1954 was renamed SAGE, for Semi- 
Automatic Ground Environment. 

Early in 1952, this team made a survey of the possible candidates 
for that task, and chose four manufacturers which seemed to be the best 
qualified for this role. They were IBM, Remington-Rand (two different 
divisions) and Raytheon. The team visited all three managements and 
reviewed their facilities. They established a set of criteria and applied 
appropriate weighting. They graded these companies on the basis of top 
management’s enthusiasm for the job, technical understanding, ability to 
get decisions made quickly, and esprit de corps. They looked at the staff, 
its availability, technical ability and enthusiasm for the project as well as 
the ability and availability of the support staff. 

They also looked at the technical contributions of the companies 
and their abilities to bring the Whirlwind II from development to produc¬ 
tion. The team evaluated the production organization, the quality of the 
field service organization and closeness between field and headquarters for 
resolution of difficulties in development and production. Finally, they 
looked into the proximity to MIT and the train travel time to the various 
headquarters. 

Each of the four men on the team made his own assessment, 
using the weights decided upon before the trip. Using the weighting 
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scheme they had agreed upon, IBM came out on top and was chosen. The 
scores were IBM, 1816; Remington-Rand, 1374; and Raytheon, 1067. 

During the course of these investigations, the Lincoln team 
interacted with the highest levels of corporate managements. For example, 
at Remington-Rand, they dealt with Leslie Groves during the day, and one 
night they were entertained on the corporate yacht by President James H. 
Rand. General Douglas MacArthur was there also. He had just joined 
Remington-Rand as chairman of the board, having been dismissed from 
his command by President Truman for insubordination. MacArthur, hav¬ 
ing had no experience with computers, did not talk about the purpose of the 
visit, but held forth instead on the interesting business of current events. At 
the end of the evening, MacArthur took the team back to their hotel in his 
limousine. 
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CHAPTER 11 


IBM BACKGROUND 


Out of the four corporations evaluated, IBM was unique in its 
holistic approach to business. IBM was founded by Thomas J. Watson, 
Sr., who had a feel not only for the sales and administrative activities of the 
company, but also for the fact that the employees’ work environment was 
very important to the success of the business. Watson seemed to believe 
that when he hired someone for IBM, he should be able to count on that 
person’s fitting into the IBM whole life picture: not only was the IBM 
product expected to be superior, but the individual engineers, production 
workers, and so on should be a credit to themselves, their families, and 
their communities. IBM believed it important that not only the workplace 
be orderly and pleasant, but that the home life of the IBM man also be 
exemplary. When we were dealing with IBM, it became clear that the IBM 
man was expected to be more than just a worker — he was part of the IBM 
family; a family that was dominated by what I called the “Tom Watson 
Code.” There were stories about the IBM dress code — an IBM man who 
was in contact with the public was expected to dress conservatively — dark 
tie and dark suit, appropriate shoes, and so on. This was evident at 
Lincoln, where a large contingent of IBM personnel was assigned to work 
on the Experimental SAGE Subsector. The IBM people, when initially 
assigned jobs in the area, would show up at Lincoln in conservative dress, 
but after a time went native. I suppose they relaxed their dress code so as 
not to draw too much attention to themselves. But the IBM man lurked just 
below the surface. The proof was aptly demonstrated on Tom Watson’s 
visits to the laboratory. As soon as his visit was announced, the blue serge 
suits were retrieved from the backs of closets and appeared, newly 
brushed, in the Lincoln hallways. 

The recreational behavior of the IBM man was also guided. 
Alcohol was bad for business; consequently, an IBM man was expected to 
turn down offers for cocktails. IBM provided its people with country 
clubs, which in turn supplied the IBM family with a vehicle where con¬ 
servative dress and sobriety were considered the norm, rather than odd 
behavior, for its members. 
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“THINK” signs were expected to be seen on every worker’s 
desk. Watson believed in symbolism of this kind. He also believed in 
group activities that would have a unifying effect on his family of workers. 
At one time, the company issued song books containing songs with 
inspirational themes to its workers. The most important benefit the IBM 
people had was job security. IBM chose the jobs they took on partly to 
maintain the level of their work force. Often, they would not bid on jobs 
where they couldn’t foresee long-term employment for their people. 
Therefore, an IBM man was not too inclined to jeopardize his job by 
fighting the code. I was impressed with what I saw. 

When the Lincoln committee that chose the computer contractor 
visited IBM, they were impressed by the esprit de corps of the company, 
and their decision was positively influenced by it. At the time we became 
connected with IBM, the family control was loosening up, partly because 
Tom Watson, Sr. was gone, and Tom Watson, Jr., who was more liberal, 
had taken over. 

IBM seemed particularly well adapted to produce the machine 
for the SAGE system because of its extensive background in computer 
development and electronics, applications design, operator training, main¬ 
tenance, and customer service as well as its large production capacity. 
IBM had, in a sense, been in the data processing business since World War 
I when it developed the card data processing system. The card data 
processing system included key punches, gang punches, vertical sorters, 
nonprinting tabulators and punched cards. These were leased to companies 
or were provided to IBM customers for use in their customer service 
offices. The punched card represented such a major breakthrough in data 
storage and classification that a short time after its introduction, it found 
extensive use in business accounting and file and retrieval systems. 

After a thorough review of the market, IBM introduced new 
processors, such as the printing tabulator in 1920 and the horizontal sorter 
in 1925. Regional IBM offices were set up to promote the service and to 
maintain the necessary equipment. Much of IBM’s investment at this time 
was in the education of operators and maintainers, and processor design 
decisions were based primarily on what IBM could profitably charge its 
customers to use the machines. 

The introduction of the 80-column card and the first accounting 
machines opened the market for IBM equipment for services in many 
different business areas. The 600 series machines provided the ability to 
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add, subtract, and multiply. In 1941, IBM participated in the development 
of the automatic sequence calculator, whose architecture was developed 
by Howard Aiken at Harvard. This calculator, called the Mark I, was 
composed entirely of electromagnetic relays. 

IBM’s first step into the use of many vacuum tubes was in the 
selective sequence calculator, which had over 12,000 vacuum tubes and 
almost twice as many relays. The selective sequence calculator was fol¬ 
lowed by the card program computer, which was all electronic. By 1950, 
IBM had a number of data processing machines to its credit, but there was 
still a demand for more capacity and speed. These demands came mainly 
from the needs of government projects for calculating weapons effects, 
and from various scientific problems which were too big for existing 
industry machinery to handle. So, in 1950, IBM decided to build another 
electronic calculator, which was called an electronic data processing 
machine. Thus were bom the 700 series machines. 

The 701 was IBM’s first high-speed electronic data processing 
machine. It consisted of the 701 itself, which was the electronic analytic 
control unit, an electrostatic storage unit, a punched card reader, a printer, 
a punched card recorder, as well as magnetic tape and dmm readers and 
recorders. The 701 was designed to be the first in a series of broad 
application machines with interchangeable peripheral components that 
allowed easy alteration and upgrading of the system. 

Although the 701 was a typical von Neumann type of machine — 
a binary, 36 bit-word machine with parallel arithmetic registers and 32 
single address instructions — it had several unusual features, such as being 
able to address half-words and the ability to use copy instructions to 
execute READ and WRITE, thereby allowing computing between the 
reading and writing of the columns of a card. The 701 also incorporated the 
Havens delay unit, a substitution for the flip-flop circuit. 

The 701 was an extremely reliable machine for its time. In 
addition to the high quality of the initial design and the rigid specifications 
for the vacuum tubes used, the 701 incorporated a cathode-ray tube 
memory, mounted in eight-tube pluggable units which could be stored on 
site and which allowed for immediate replacement if necessary. Also, 
subsystem components were constructed and housed in individual boxes; 
this permitted extensive individual and parallel testing prior to integrated 
testing. User programs were interchangeable among 700 series machines; 
thus IBM could test customers’ programs before delivery. The effects of 
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the SAGE computer’s development were first felt in the 700 series machine 
in the 704, which included a random access core memory of the Whirlwind 
II kind. Other IBM machines would incorporate some of the other compo¬ 
nents developed for the SAGE computer. 
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CHAPTER 12 


LINCOLN MEETS IBM 


After IBM was selected as the preferred manufacturer for the 
Whirlwind II computer, the Air Force and Lincoln were faced with the 
problem of getting IBM on contract. After some deliberation it was 
decided that Lincoln would provide IBM with a subcontract and, about 
December 1952, such a subcontract was signed. The purpose of this 
subcontract was basically to bring IBM up to speed and, in the process, to 
help both IBM and Lincoln establish their respective roles and working 
relationship in such a way that both organizations could contribute to their 
maximum ability. On the strength of this subcontract, and with the expec¬ 
tation that it would be brought on as the prime contractor by the Air Force 
to produce the Whirlwind II machine, IBM quickly procured an old 
necktie factory on High Street in Poughkeepsie, New York, and assigned a 
number of engineers to the task of formulating an assessment of what the 
job would entail. Consequently, the IBM project was called Project High. 
The first IBM people on the job were John M. Coombs, Morton M. 
Astrahan, and Walker H. Thomas. 

Within Division 6, Group 62 guided IBM in the design of 
Whirlwind II, and Group 61 and the Cape Cod System provided guidance 
in system concepts, data capacity requirements and the computer instruc¬ 
tion repertoire. There were a number of common points of reference. 
Beyond agreeing on the twin goals of speed and reliability, the Whirlwind 
II machine had to have a processing capacity commensurate with the 
SAGE system design objective of 300 tracks; it had to generate a certain 
number of displays and provide guidance and instruction to interceptors. 
Another common point of reference was the knowledge of the statistics of 
operational programs, such as the rate of usage of each of the instructions 
in the order code. These common points of reference gave us a framework 
which disciplined the feedback to the computer’s design. 

The Lincoln Whirlwind II team organized itself along several 
major subsystem lines. There was an arithmetic element section, a mem¬ 
ory section, drum design section, and so forth. IBM fell into a similar 
organizational pattern, and these counterpart groups then began the work 
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of trying to design the system on a joint basis. The Lincoln group, fresh 
from its experience with Whirlwind I and the Cape Cod System design, 
tended to view the IBM task as that of packaging Whirlwind devices so the 
system could be reproduced easily and quickly. On the other hand, most of 
the IBM people who were either currently working in the laboratory or had 
had experience with the IBM 701 computer development believed that the 
best way to proceed was to use the methodology which was then standard 
in the company. The first several months were a period of considerable 
stress on the parts of both teams trying to find complementary roles. In 
order to meet the tight schedule, which called for delivery of a machine 
ready for field use in just three years (by 1956), it was essential that the 
main elements of the design be completed within a year or less. 

In the forming of counterpart groups to carry out the design of the 
Whirlwind II, IBM set up a group under Harold D. Ross as counterpart to 
the Lincoln arithmetic element section which I headed. Ross’ group con¬ 
centrated on circuitry design and circuitry choices while my section con¬ 
centrated on overall CPU design. Although my section sometimes 
interacted with Ross formally, the greater interaction took place among the 
people around Morton Astrahan, who were doing most of the CPU logical 
design. His group included B. L. Sarahan, Walker Thomas, and Bennett 
Houseman. At MIT, my section included, among others, Richard C. 
Jeffrey, Rollin P. Mayer, Samuel L. Thompson, and Robert J. Callahan. 

Astrahan and Thomas had come to Project High from the 701 
program, IBM’s defense computer project. Astrahan acted as the leader of 
the logical design group at IBM. He was a bright, aggressive and assured 
man. Although he was not in a position of great responsibility at that time 
in the IBM organization, his influence on the computer design was greater 
than most of his superiors. Astrahan was clearly the most innovative of the 
people working on CPU design, and he vigorously supported his proposed 
designs. This aggressiveness at first created resentment in my section, but 
the quality of his thinking merited the success he was to achieve. 

Our first discussions about the design of Whirlwind II reflected 
our respective organizational backgrounds. We were anxious to develop 
the techniques we had learned through experience on Whirlwind I. The 
Lincoln people preferred a variation of the Eccles-Jordan flip-flop as a 
register element, whereas the IBM people were inclined toward the 
Havens delay unit. After many discussions, the flip-flop was chosen. IBM 
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also had developed an electrostatic storage tube that seemed to work quite 
well, and IBM was advocating its use. 

Lincoln people had begun to meet with Astrahan’s group begin¬ 
ning in late 1952 — even before the contract was signed. The deliberations 
of this joint group led it to the conclusion that the single address order code 
ought to be used and that a 16-bit word length would be sufficient to give 
the precision and dynamic range required for the air defense job. However, 
everyone felt that to allow for expanding the high-speed memory capacity 
from 2048 to 16,384 words, we would need between 11 and 14 bits for 
address. The operational code would take six bits for the selection of 64 
basic instruction code words and the inclusion of automatic indexing in the 
machine would also require about five bits. This all added up to a single 
address instruction which varied from 25 to 28 bits, and which was larger 
than the data word length, 16. There was some talk of word lengths bigger 
than 16 bits to cover the needs of single address instruction word lengths 
of 28. 

During these conversations, the observation was made that most 
of the data used by the machine in SAGE was positional data and would 
be in Cartesian coordinates, having an X component and a Y component 
(each requiring 16 bits), and that both numbers had to be operated on in the 
process of tracking, thus taking up a great part of the machine capacity. 
The suggestion arose out of these conversations that in order to avoid 
having a 32-bit word length, part of the instruction code could call out a 
single data register which contained both the X and Y elements of the 
position data. Examining the consequences of looking at it this way, it 
appeared that if both parts of the position data were operated upon simulta¬ 
neously instead of in sequence, you could reduce by perhaps half or more 
the number of instructions that would be required. This led to the idea of 
building a dual arithmetic element. 

We also studied the payoff of using index registers for stepping 
through the series of addresses either to bring out the instruction code in 
proper sequence or to step through the data. The index register basically 
held address data, which was automatically indexed as the program contin¬ 
ued to process blocks of tracking data. We also determined that it would be 
beneficial if the input/output equipment were asynchronous to the CPU; 
thus, some buffering would be required between the CPU and the input/ 
output elements. This called for the use of drums, and to save computing 
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time required an interrupt mode which would search the drums for the next 
piece of data required when the central computer was free. 

SAGE would be the first digital computer system to provide 
facilities for time-sharing of a common data base and displaying different 
functions such as tracking, air surveillance, and weapons direction. Actu¬ 
ally, the first display consoles were designed to control the operation of the 
Cape Cod System from the Barta Building direction center. As the SAGE 
computer prototype, known by now as XD-1, became operational, the 
location of the Cape Cod System direction center shifted from Cambridge 
to Building F at Lincoln, which housed the XD-1. These consoles required 
a major portion of the power consumed by the system. 

In the Cape Cod System, the display console image was contin¬ 
ually refreshed through the CPU; that is, by a sequence of programs 
devoted to the task of refreshing the picture before the characters had 
decayed due to the lack of persistence of the phosphor. This method of 
retaining the picture was very costly in its use of the CPU’s arithmetic 
element, so a set of magnetic drums was added to be used in the task of 
renewing the display at three-second intervals. A problem concerning the 
display console was its layout. No one had ever built one before. Deter¬ 
mining the best angle for the face plate covering the display tube itself was 
the subject of concern of many human factors engineers. Bob Wieser 
remembers the experiment that Dave Israel designed that led to the answer. 
A display tube shipping carton was suspended from the ceiling by four 
strings. The outline of the tube face was drawn on one end of the carton. 
People were seated in front of the mock-up and were asked to adjust its 
position by pulling the strings until they arrived at the best height and tilt 
angle. The heights at the front and rear of the carton were measured and 
recorded. After many trials, the measurements were averaged; these aver¬ 
ages were used in the final design. 

Poor readability of the display screen, along with resultant oper¬ 
ator fatigue, were major problems to be solved. An elaborate scheme was 
designed and employed to solve them. The most serious problem was the 
reflection of the room lighting off the surface of the glass covering the 
display. Looking at the display was like driving at night with the dome 
light on, always seeing its reflection in the windshield. Further, the display 
itself was difficult to read because of the lack of brightness: the phosphor 
chosen created a blue-green initial color, followed by a yellow afterglow 
that persisted. To enhance readability, the room light was filtered. This 



filtering was accomplished by enclosing the fluorescent room lights in 
plastic sleeves that fit over the tubes, eliminating portions of the visual 
spectrum that competed with the flash and the afterglow. The majority of 
the light from the fluorescent tubes was thus blocked. Even the remaining 
light that was allowed to filter through was collimated by a honeycombed 
ceiling. This set-up did not correspond to the specifications used by the Air 
Force in establishing lighting plans for buildings, and it contributed to 
Lincoln’s reputation for “gold plating” — but it worked. 

The work on the displays brought out practitioners of the rela¬ 
tively new field of “human engineering” — a field concerned with the 
match between machine and operator. Each of the companies involved in 
the design and fabrication of the various parts of the SAGE system had 
acquired their own “human factors engineers.” These people, who had 
usually majored in psychology, commented on all aspects of the design, 
giving particular thought to the interactions between the machine and the 
man. Lincoln followed the trend by setting up a psychology group under a 
Ph.D. who had the improbable name of Fred Frick. Frick (who was the 
nephew of the baseball commissioner of that time) assigned a Dr. James 
W. Degan to help with the SAGE design. Because there was no standard 
approach in human engineering and because many of the rules its practi¬ 
tioners followed were subjective, each psychologist tended to follow his 
own different drummer. This inevitably led them into interminable argu¬ 
ments about how the human fit into the design. It finally got so compli¬ 
cated that the role the human engineers played in the SAGE design was 
brushed off to an advisory capacity so their arguments didn’t disturb 
anybody. Both the Lincoln and IBM engineers then relied on their own 
judgment, prodded here and there by advice from our human factors 
group. 

Degan was a short, balding man who had graduated from the 
University of Chicago with a degree in psychology. He spent much of his 
time analyzing the procedures that the display console operators were 
expected to perform. He had had no significant management experience or 
training. He was largely a passive person who concentrated on acquiring 
talented people to do the work. He was successful at this, but his passivity 
tended to turn off his colleagues and his input would often get lost in the 
internecine squabbles. Degan was competent in his field, although he had 
trouble with communication within his group and division. You could 
count on him for thoughtful analysis and good judgment, but not for 
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recommendations. He had a reputation for failing to show up on time at the 
meetings he was invited to, and when he was traveling, he would more 
often than not dig too deeply into the nightlife of the cities he visited. 

The Cape Cod display console constmcted at Lincoln was a 
prototype for the SAGE production models. For the SAGE system, IBM 
subcontracted to Bendix for the hardware, and used the Charactron and 
Typotron cathode ray tubes provided by Convair and Hughes, respec¬ 
tively. Lincoln people working on the display consoles included Steve 
Dodd, Charles L. “Chuck” Corderman, and Pat Youtz. The SAGE dis¬ 
plays became a basis for their future work on remote terminals. At IBM, 
the displays were managed by Ralph G. Mork, and contracted through the 
Bendix Corporation. Mork was a hard-driving project leader who was 
stationed at IBM’s Endicott facility in central New York State, and thus he 
was somewhat isolated from the rest of the computer manufacturing. Mork 
was his own man, and, although he made an effort to please his own 
management as well as the Lincoln people, he ran his own show. People 
remembered him for the eccentric way he smoked his cigarette. He would 
clamp the filter between his front teeth and then have to close his mouth 
over the filter in order to puff at it. It was very disconcerting, and one got 
the impression that he did it to distract his visitors. He accomplished that. 

Although we worked well with IBM on an informal basis and 
were able to resolve many important design questions, none of the Lin- 
coln-IBM work could be implemented until a formal mechanism was 
established for making joint decisions. 
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CHAPTER 13 


THE HARTFORD MEETINGS 


Ms a first step toward joint consensus on the design of Whirl¬ 
wind II, the IBM and Lincoln managements decided that several confer¬ 
ences would be held at a point about halfway between Poughkeepsie, New 
York and Lexington or Cambridge, Massachusetts. The managements, 
having sensed the competitive instincts and healthy rivalry of the two 
teams, decided on a halfway point as a symbol of the evenness of the two 
groups. Hartford, Connecticut was chosen. These meetings were designed 
to ensure that there would be an exchange of knowledge and technology 
between Lincoln and IBM as well as to provide an opportunity for IBM and 
Lincoln to review each other’s work. They were also an important device 
for illuminating potential problem areas and for introducing people on both 
sides to each other. About 20 people were designated as a design manage¬ 
ment committee for the Hartford Meetings, with about ten from MIT and 
ten from IBM. I was included because I was working on the arithmetic 
element and the general logic design of the system, and was able to attend 
all of the meetings. 

The first Hartford meeting was held on January 20, 1953. Jay 
Forrester was the first Lincoln speaker, and he described the background 
of the program. I thought his speech was a good summary, and it appar¬ 
ently was compatible with IBM’s position on the relationship. Lincoln, 
according to Forrester, was devoted to research and development, and not 
to production. To get the system into production, it would be necessary to 
collaborate with industrial companies, such as IBM, which had the neces¬ 
sary administration and facilities to handle the design, construction, 
deployment, and maintenance that the production of hardware would 
require. Forrester recognized that this kind of collaboration was unusual; it 
was a relationship bom of necessity. The program was urgent, he said, and 
a prototype system was required by 1954. He noted that there was no 
computer in existence — including the Whirlwind I and the IBM 701 — 
which would be suitable for the transition system as it had been docu¬ 
mented in Technical Memo (TM) 20. The existing machines did not have 
the reliability required for the job nor did they have the specialized 
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peripherals that would be needed. Forrester noted that the Cape Cod 
System, which was being put together as an example of the proposed 
system, could be quickly modified for production in a TM 20-like system 
architecture; therefore, he suggested that IBM place a representative at the 
Cape Cod facilities. Forrester concluded his talk with a description of the 
status of Whirlwind II thinking at MIT and included implicitly and explic¬ 
itly what Lincoln thought IBM’s role should be in the program. Forrester’s 
talk was followed at the conference by discussions of several important 
topics, such as the current status of the thinking about the arithmetic 
element, basic circuits, input-output equipment, principles of designs, 
proposal for the logical design of the Whirlwind II computer, magnetic 
memory, and core production status. Also discussed were plans for the 
memory test computer, other magnetic core applications, buffer storage 
and display, component reliability, and, finally, the schedule. 

Near the end of the program, Lincoln’s Norm Taylor discussed 
the schedule. Taylor told the group that Lincoln’s objective was to have the 
prototype computer with its associated equipment installed and operating 
by Januaiy 1, 1955. If seven months were required for final installation, 
testing and integration of the equipment in the air defense system, and nine 
months were required for procurement of materials and construction of the 
model, there would be about nine months left for all the engineering work 
necessary to prepare specifications, block diagrams, development of basic 
circuit units, special equipment design, and to do all the other things 
necessary to permit actual construction to begin. The schedule for all this 
work was very tight, and Taylor estimated that about 235 professionals 
were needed on the program right away (at that time, about 20 percent of 
that number were assigned). 

The meeting was concluded with a talk by T. A. Burke of IBM 
who indicated IBM’s current status on the subcontract, which would end in 
three months . IBM had spent the time so far learning about the project and 
getting its own house ready to undertake the assignment. According to 
Burke, 25 people had been assigned to the project, $130,000 worth of test 
equipment had been purchased, and the building on High Street which had 
been procured was currently undergoing certain necessary modifications. 
The most serious problem that Burke brought out for discussion was the 
uncertain status of the Air Force prime contract, which he saw as a follow- 
on to the Lincoln subcontract. The first meeting had been constructive, 
and set the tone for follow-up. 
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A second joint meeting was held three months later in Hartford 
on April 21. The first meeting had resulted in the formation of a number of 
committees made up of IBM and Lincoln engineers who were to draw 
conclusions concerning the character of the subsystems. This second 
meeting was basically a report of the findings of the committees. A great 
deal of progress had been made on the design of the arithmetic element, the 
control subsystems, and the magnetic core memory. Good progress was 
reported on the input-output committee work. It was agreed that better 
coordination should be achieved in the basic circuit activities, and it was 
proposed that a power supply committee be formed to make judgments 
about the design of the power supply. There was also some progress 
reported on standards. The main results of this meeting were a better 
understanding on the part of the joint management group of the current 
status of their deliberations and decisions, a feeling for the status of the 
decisions that were being made, and the discovery that these were not 
occurring at a rate commensurate with the needs of the schedule which had 
been established for the design of the system. 

While waiting for the committees to act, Forrester, Taylor and 
Everett tried to get a better fix on what had to be done to assure the 
schedule. In their zeal to obtain this knowledge, they analyzed all of the 
activities that went into production, often to the annoyance of the people 
responsible for these activities. In talking to the IBM man responsible for 
supervising the factory, Forrester apparently pushed too hard, for he was 
told, “You run your-ing university and I’ll run my-ing factory!” 

On May 21, 1953, the third Hartford meeting was held, this time 
to deal with packaging of Whirlwind II. Much of the meeting was spent 
considering the standardization of pluggable units. It was agreed that the 
mechanical design group should proceed with the design of a six-tube 
pluggable unit, but at the same time continue with the design of the four- 
and nine-tube units in case they might be needed. One of the problems in 
pluggable unit design was to maintain an even, cool temperature around 
the vacuum tubes. An important innovation, the brainchild of Norm 
Taylor, took advantage of the fact that the pluggable unit racks could be 
stacked up to form a plenum for cool air under pressure. The air was forced 
in around the phenolic component boards inside the racks, and then 
escaped out into the room through the annular rings at the base of the tubes, 
thus cooling the tubes uniformly. Another meeting on packaging was held 
on June 1, 1953. More time was spent on standardization of pluggable 
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units, and sketches of the pluggable unit design were shown. Also, the 
design of the central machine was described. 

These Hartford meetings provided opportunity for an exchange 
of information, acted as a catalyst for initiating action, provided the means 
of identifying overlooked aspects of the machine, and served as a forum in 
which people could interact on a personal level. By the time of the fifth and 
last Hartford meeting on June 15, a modus operandi had been established 
between the IBM and the Lincoln staffs. 

John Coombs was the senior IBM person assigned to the project. 
He had earlier been hired from Engineering Research Associates in Min¬ 
neapolis and now held the position of project leader of Project High. 
Coombs was a gentle man — not a very dynamic person. In fact, some at 
Lincoln thought him a little too passive. I remember talking to him once 
after there had been a clash of personalities on the arithmetic element 
design team. We had been pushing for the inclusion of the fast adder into 
the arithmetic element, and one of the IBM people, a man named Richard 
Richards (who had changed his name recently from Richard Steinberg), 
insisted that we did not have time to think about including something new. 
(This struck me as particularly ironic at the time, because in the room in 
which we were working at IBM, all of the desks had THINK signs facing 
out at us.) Richards was acutely aware of the short time schedule, and he 
was advocating replication of the best known design. I lost my temper 
because I felt he was obstructing the progress of the meeting, and I went to 
Coombs to complain about his behavior. Coombs, in his philosophical 
way, compared the situation to what goes on on the stage: We are all 
actors, he said, and each of the roles we play is a role forced on us by the 
circumstances we find ourselves in. I thought the exchange told a lot about 
Coombs’ passive nature. 

IBM seemed to have the knack of balancing its management 
teams. Coombs reported to a man named J. E. Zollinger who was at IBM 
World Headquarters in New York. Zollinger was a real go-getter: an 
aggressive, rough-cut sort of man who was noted for his salty talk — not at 
all a typical blue suit, white shirt, black tie IBM man. His contracting 
philosophy could be summed up in a statement he himself once made: that 
he always gave his customers a little of what they wanted so he could sell 
them what they needed. Zollinger usually attended the high-level meetings 
between Lincoln and IBM when SAGE was being discussed, but, when he 
was unavailable, his assistant, Glen Solomon, attended in his place. 
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Solomon’s personality was in direct contrast with the brash personality of 
Zollinger. He was the real statesman of the contracting business: smooth, 
bright, diplomatic, and adept at smoothing the feathers Zollinger regularly 
ruffled. 

Much had been accomplished during the Hartford meetings, but 
in the judgment of the Lincoln management, decisions had to be made 
faster if the schedule was to be met. There was not enough time to really 
study and contemplate the alternatives available, so choices had to be 
made primarily on the basis of the experience the individuals had already 
had with the subject area under consideration. 
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CHAPTER- 14 


PROJECT GRIND 


In order to actually produce an experimental prototype by 1955, 
Lincoln and IBM managements established an effort called Project Grind. 
Project Grind took the form of a series of meetings held back-to-back, 
essentially to grind out the necessary design decisions. This exposed many 
of the differences in approach of the two groups, but it also established a 
forum in which alternative choices could be examined in some detail. 
There were seven Project Grind meetings between June 24 and July 15, 
1953, resulting in an embryonic system design with issues identified and 
people assigned to address those issues. I took part in all the meetings, and 
remember them as productive. But as the meetings went on, the need for a 
formal mechanism for design approval became obvious. It also became 
clear that not only IBM and Lincoln Division 6 were involved, but the rest 
of Lincoln, other associated contractors, and various parts of the Air Force 
were involved as well. Not only did the computer have to be manufac¬ 
tured, but changes had to be made in the communications system, the 
computer program, the radar sites, and the connections with Nike ground- 
to-air missiles and interceptor bases. Additionally, certain changes were 
needed in the relationship with the Army concerning anti-aircraft systems, 
with the Navy concerning picket ship inputs, and with the Civil Aeronau¬ 
tics Authority (the predecessor of the FAA) concerning air traffic control 
matters. 

By this time, IBM had a prime contract from the Air Force. In 
order to identify the machine under design with IBM as well as with MIT, 
it was decided that the Whirlwind II name would be dropped in favor of Air 
Force nomenclature, and the system was given an Air Force number, 
AN/FSQ-7. This designation would be informally shortened to “FSQ-7” 
or simply “Q-7.” An AN/FSQ-7 planning group was identified, with 
members drawn from both IBM and Lincoln. 

The procedure that was followed in the Project Grind meetings 
consisted of taking subsystems one at a time and forging whatever deci¬ 
sions could be made based on existing background and knowledge. Min¬ 
utes of the meetings were taken in order to put on record some of the 
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decisions as they were made and some of the reasons for those decisions. 
Any problem could be brought into the open and discussed so that deci¬ 
sions could be made as soon as possible. Toward this end it was also agreed 
that everyone should feel free to present even tentative plans for various 
parts of the system, with the general understanding that they were tenta¬ 
tive. Any errors or omissions would be called to the attention of the authors 
of the minutes. 

The first meeting was devoted to the radar inputs. Slowed-down 
video inputs, video mappers, and slowed-down video input registers were 
discussed, and a general design description of the input registers was 
agreed upon. The subjects of the second meeting, held June 25, were 
marginal checking, power supplies and magnetic memory. At the third 
meeting on June 26 on magnetic drums, it was tentatively agreed that there 
would be six fields per physical drum, and five physical drums in the 
computer. The fourth meeting, held June 30th, was concerned with output 
display systems. A display rate once every two seconds was tentatively 
accepted. It was agreed that there would be 16 words per track, allowing 
for display of the history of all tracks. It was also agreed that the system 
was to operate with a minimum of degradation even when only one 
computer was functioning. The fifth meeting, July 1, was concerned with 
cross-telling, output drums, output links for digital information on a 
display maintenance console, and mechanical design. At the sixth meet¬ 
ing, July 2, the concern was standard circuits and the action of the 
Standards Committee. All tube types to be used were definitely approved, 
and it was decided that one-tenth microsecond pulses would be used 
wherever possible in the system. It was generally agreed that a project 
meeting should be held at least once every other week. The seventh and 
last meeting discussed mapper subcontracts, cross-telling, review of the 
drums, paper tape machines, input counters, manual inputs and power 
supplies. It was agreed that paper tape would not be used in the FSQ-7 
unless there was good reason to do so. 

Project Grind resulted in fewer decisions than the Lincoln group 
had considered necessary to meet the schedule, but it had a remarkably 
positive effect on the working relations of the people involved. It also 
demonstrated the real need for some means or technique to help people in 
the process of coming to a consensus on various aspects of the system 
design in an orderly way, and this at a level of detail which was great 
enough to ensure that the major outline of the design was visible, but not so 
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detailed that the judgment of it could only be made after all the drawings 
and design details had been worked out. It was the need for such means 
that eventually prompted Lincoln to set up a Systems Office, which I was 
to head. We did maintain an industrial liaison office under Art Kromer, an 
experienced administrator hired from Western Electric, and one of the few 
people on the project with grey in his hair (he had grey sideburns). Art 
added a touch of maturity to the picture we presented, but the scope of his 
office was limited in part by his own training — we used to say that you 
couldn’t become a supervisor in the Bell System until you were ready to 
retire. We called him “Greylocks.” He was a pleasant, conscientious man 
who was not given to initiating action. He might have been the man for the 
Systems Office had he not felt uncomfortable working in the loose struc¬ 
ture he faced in Division 6. 

The Systems Office would be aimed primarily at consensus 
formation, and it was one way that the technology was transferred from 
Lincoln to IBM. In addition, senior Lincoln people like Gus O’Brien and 
Ken Olsen were moved to Poughkeepsie to monitor progress and to be 
available first-hand to apply the lessons learned from Whirlwind I to the 
design of the FSQ-7. As it turned out, this was an effective means for 
managing the transfer of technology. 
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CHAPTER 15 


GENESIS OF THE SYSTEMS OFFICE 


One of the key results of the Hartford Meetings and Project 
Grind was the creation of Lincoln and IBM subcommittees to establish the 
FSQ-7 subsystem designs. The subcommittees forced the integration of 
Lincoln and IBM engineers, and although each had their own approaches 
to design, the groups were surprisingly harmonious and most of the time 
were in agreement on the design of particular FSQ-7 components and 
subsystems. However, a problem that had not been solved by the creation 
of subcommittees was the seemingly simple matter of the routing and 
signing off of the designs through those groups that would be affected. 
Even though subcommittee members felt they had achieved a reasonable 
design, their work still required some official signature or announcement 
to give it status so that the necessary contracts and work statements could 
then be properly written. 

Although several organizations were directly involved, the 
responsibilities for design management did not fall plainly into the lap of 
any one of them. IBM, Burroughs, and Western Electric were prime 
contractors. The Air Force was just starting up its System Program Office 
in New York City, while the Air Defense Command maintained a planning 
group at its headquarters in Colorado Springs, and an ADC contingent was 
housed at Bedford. Additionally, Lincoln’s management interpreted Lin¬ 
coln’s charter to mean that Lincoln was to be research-oriented only, and 
that it was not to be an architectural engineering firm that might have taken 
on the design management task. 

In the case of the FSQ-7’s basic circuits, whose designs were 
reaching completion at both Lincoln and IBM, I took the initiative myself, 
after consulting with Taylor and Everett, to gather together all of the 
information and design justifications which then existed on the circuits. I 
solicited inputs from the Air Force and those contractors who would be 
affected by the design, and spent a great deal of time getting these people 
to try to arrive at a consensus. Since effecting this consensus required so 
much time and effort and great patience, in this area we also relied heavily 
upon several other people, including Richard L. Best and Ron Mayer. 
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Dick Best was the principal Lincoln Division 6 circuits man; he 
had contributed significantly to the selection and design of the Whirlwind I 
basic circuitry. For the FSQ-7, he took part in both the design and the 
evaluation of the basic circuits. An uncomplicated and dedicated person, 
he was rather tall, very slightly built, and he spoke in a very soft voice that 
nonetheless carried considerable authority based on past experience and 
performance. He had been a great help to me when I was working on 
transistors, and even more of a help while we were trying to settle on the 
basic circuits. People liked to have him on their projects because of his 
guilelessness and lack of game-playing. He had achieved a certain notori¬ 
ety around the lab for a book that he and his wife had published on folk 
songs of America. What could have shaped up to be a partisan fight 
between IBM and Lincoln became a competition in performance of the 
candidate circuitry. It was so clear that Best was objective about his choice 
of circuits that both IBM and Lincoln trusted his judgment. 

Ron Mayer was also very important to the Systems Office pro¬ 
cess. I had heard about Ron Mayer before I ever met him. It was said 
around the lab that Ron could draw the block diagrams of Whirlwind on 
the head of a pin. Since Ron had worked on the Whirlwind I block 
diagrams for Bob Everett, he was assigned to me because I was then 
responsible for the FSQ-7 arithmetic element and for overseeing the 
logical design of the central computer element. Ron worked out a set of 
symbols for all of the logic elements used in a computer: registers, gates, 
and so on. He had devised a way of outlining the whole computer in terms 
of these symbols and block diagrams, so that the entire logical design 
could be reproduced on an 8 Vi x 11 sheet of paper. Ron lived and breathed 
computers. He became famous for writing the first program to play music 
on the Whirlwind, and he also programmed some of the digital graphics 
used in the early computer program demonstrations. During one of the 
design reviews of one of the FSQ-7 elements, I shared a hotel room with 
him. He loved to talk about where the computer business was going, and 
had a vision in which computers would take over the majority of functions 
performed by humans. This take-over would become so pervasive that 
people would lose their ability to perform any functions that computers 
could perform. In the final analysis, he said, it would come down to a 
moral question of whether or not the plug should be pulled on the com¬ 
puter; because, if this were to be done, man would then be without all 
those functions around which he had built his life. 
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In the absence of a designated authority within Lincoln or the Air 
Force, the first principle of behavior for the Systems Office was to shun the 
appearance of representing oneself as authority. So, with this in mind, I 
began with the easy decisions, those that were well within the scope of 
Group 62. We gathered together all of the backup documentation we 
could, including the design proposed by the appropriate subcommittee. 
We then did an analysis of the design, and proceeded to draw conclusions 
which were primarily concensus-oriented — that is, conclusions that 
tended to be the least unacceptable to any of the affected parties: Division 
6, Division 2, the Lincoln Project Office, the Air Force and participating 
contractors. I then wrote a brief, summarized the conclusion, formulated 
the action to be taken by all of the parties and solicited the signatures of 
those who were in a position to block the action. 

Our own organization of a group to handle the design control 
problem prompted IBM to set up a counterpart group, which was called the 
Engineering Design Office (EDO) and was manned by three senior staff 
people, and reported to Robert P. Crago who would shortly take over the 
whole project. Although John Coombs was the IBM project leader to begin 
with, the slippage in the rate at which decisions were made at IBM 
prompted him to take on Bob Crago, who then had charge of the IBM drum 
group, and to put him in second place under himself. Crago was an 
ambitious, quick-witted engineer who was willing to do what was neces¬ 
sary to ensure that IBM met its schedule. He took on the job of trying to 
gain control of the IBM design process and matching it better with the 
capabilities of their production departments. Crago, in order to provide 
himself some running room, would not be tied down by a nit-picking 
review process. He insisted that the less important decisions should be the 
prerogative of the IBM people in charge of the subsystems; indeed, much 
of his time was spent loosening the grip of Lincoln on IBM operations. In 
general, Lincoln agreed to go along with him as long as IBM provided 
reasonable feedback. Crago rose in the IBM hierarchy until he was given 
practically full charge of the operation and then, finally, replaced Coombs. 
Largely due to promotion by Forrester and Everett, he would be named the 
outstanding young engineer of the year in 1957 by Eta Kappa Nu. 

It was relatively easy to prepare briefs for the basic circuits, the 
instruction set and the arithmetic element, because these were computer 
problems and the computer expertise was clearly in Lincoln’s Division 6.1 
knew who was involved and who had the authority to make design 
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choices. But a difficult “political” situation existed between Division 2 
and Division 6. Although my procedure brought together all groups 
affected by a design, it could not become formalized immediately as part 
of the standard Lincoln procedures because of the tension between Forres¬ 
ter and Valley and their two divisions. 

Nonetheless, several more briefs were successfully produced. 
Those of us in the Systems Office involved in their production made 
conscious attempts to gain the confidence of all the participants. We strove 
to be objective and not to take sides in the design. We did not give 
ourselves titles and we worked around the line structure. Rather than 
operating formally as a whole division ourselves, we worked within other 
divisions and groups — we sort of floated in a sea of ideas, special interests 
and proposals, and our unobtrusiveness was effective. It wasn’t until 1957 
that the Systems Office attained enough history of successes to be recog¬ 
nized as a Lincoln group. 

All this is not to say that a near-optimal result was always 
achieved. The example of the control panel is one of the exceptions. The 
Lincoln and IBM designers of the FSQ-7 were influenced by their own 
respective backgrounds, having built machines that had different objec¬ 
tives. The IBM people had developed a series of machines (directed at 
business activities) using large numbers of vacuum tubes, which did not 
require the reliability and the speed needed by a real-time control applica¬ 
tion. In addition, they tended to be satisfied with the reliability they could 
achieve using more or less standard radio and radar circuitry. Lincoln’s 
concern for the reliability and speed needed in real-time applications led 
them to employ test aids, such as machine-directed marginal checking. 

To make it easier to isolate programming and machine errors, 
every register in Whirlwind was displayed on the control console. Two 
neon bulbs indicated the presence of a one or zero in each of the individual 
digit registers. The IBM people, on the other hand, tended to depend on 
printouts of register contents. The trouble with that was that machine 
errors and programming errors both contributed to the printout, so it was 
difficult to sort out the two. In the design of the FSQ-7 control console, 
there were many arguments about the cost benefit of the very large number 
of neon lights and their controlling circuitry. Lincoln prevailed, however, 
with the concession that one light per digit register would be satisfactory. 
With these lights the machine operator and the programmer could step 
through the program and see where the error or failure had occurred. After 
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the design was fixed, everyone was amazed by the size of the control 
console. It was about 15 feet long and three or four feet high and was 
covered with lines of lights which could be used both by the programmer 
and the maintenance people. The final judgment was that such additional 
costs, though justified in the experimental XD-1 machine, would not 
really be necessary in the production machines. Nevertheless, all FSQ-7s 
were built with this control panel. 

Once our procedure on preparation of briefs was firmly estab¬ 
lished, it was institutionalized and extended to the subsystems which were 
outside the responsibility of Division 6. The procedure resulted in a 
document which was later to become known as a TIR (Technical Informa¬ 
tion Release), the mechanism for reporting to the Air Force what the 
design was and what should be done with it so that it could work in concert 
with other contractors’ designs. The TIR was a package which contained 
the design specifications, pertinent background to the design problem, 
analysis papers, supporting material for the recommendations, and of 
course, the recommendations themselves. The TIR was delivered to the 
Program Office, where it was accepted as the formal input upon which the 
Air Force could then act. At the Systems Office, the TIR moved up 
through a list of selected signatories, those who had to sign off before the 
Air Force would take action. 

Part of the success of the operation of the Systems Office was due 
to careful attention to the words that describe what the Systems Office did. 
What it did came close to what is now called configuration management 
(we called it design control). We called its output a “Technical Informa¬ 
tion Release,” thus avoiding the question of whether it was directive or 
not, or of who was in charge. It appeared on the surface that this was 
advice to the military and had no force except that which the Air Force 
chose to give it. Some people felt that there should be a design group or 
person responsible for directing the design. However, we could not put out 
a directive because that would force the organization to determine who was 
in charge. There were people at various levels in the organization who felt 
they needed this authority in order to take responsibility for the result. 
There were many others who would not subordinate themselves. Although 
the Air Force had all the authority it needed to designate someone in its 
own organization to be responsible for the design, this responsibility was 
precluded by the fact that the Air Force did not have the technical capabil¬ 
ity to effectively monitor the design as it progressed, much less initiate it. 


67 



So for every design decision which was made, a list of opinion leaders was 
drawn up. This was a list of people who were expected to concur on the 
contents of the technical information release. We dug up the word “con¬ 
currence.” The words “direct” and “control” were too strong. “Oversee” 
and “coordinate” were too weak. But concurrence had the right feel — it 
gave everyone who was named as necessary to support the technical 
information release the implied power to veto what was being included in 
the TIR. The word “concurrence” provided a dignified way for the 
principals who managed the system to effect changes without answering 
the question of who was in charge. 

What had begun in late 1953 as a diplomatic method of reaching 
design consensus thus ended up as a full-fledged Lincoln group devoted to 
Design Control. I feel that some of my own best work went into the pre¬ 
paration of those early briefs; work which is not as evident in the subse¬ 
quent documentation as was work of far less influence and importance. 
The success of this deliberate deemphasis of authority was actually a kind 
of testimony to the effectiveness of Taylor’s, Forrester’s and Everett’s 
private and pragmatic solution to an otherwise difficult and touchy issue. 
The Systems Office taught its participants, as well as many in the organiza¬ 
tion, a form of diplomatic maneuvering which, in time, would be accepted 
as a normal way of doing business. 

While these approval procedures were evolving, an arrangement 
had been made in which Jay Forrester’s signature was required for final 
approval before a design could be presented to the Air Force. Although the 
IBM team respected Jay, he often tried their patience. He, Bob Everett and 
Norm Taylor had a way of spotting design flaws — especially those re¬ 
sulting from the fact that the FSQ-7’s various subsystems had been 
designed by different groups. 

Several times during the design of the FSQ-7, criticisms by these 
three men led to major design revisions. Jay, especially, felt free to 
comment on anything, and often he angered those whose work was under 
criticism. Most of the time, his suggestions were well-founded and IBM 
complied, but occasionally his suggestions seemed to IBM to border on the 
whimsical, especially given the realities of production and schedules. In 
one case, he called for extensive “aging tests” to be performed on the 
circuits to be used in the SAGE computer, arguing that when the computer 
was running, the little-understood phenomenon of “silver migration” 
might occur, wherein the silver which lined the holes of the phenolic 
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boards would spread or migrate across the surface of the boards. Since this 
was possible, he argued, it was also possible that migration could short out 
the circuits and crash the whole system. IBM’s position was that running 
the tests to see if this phenomenon might take place and threaten the circuit 
board design integrity would be disastrous to the schedule of the project. 
Further, they said, the system would have to go through a major redesign, 
and that an automatic circuit board assembler which had been contracted to 
General Mills would have to be modified as well. Forrester still insisted 
the tests be run. At that point, IBM had its own engineers look into the 
technical risk, and they satisfied themselves that no problem would occur. 
Forrester accepted their analysis with good grace, and the tests were never 
run.* As can be imagined, Forrester drew mixed reviews from the IBM 
staff; their reactions to his varied inputs ran the gamut from “pronounce¬ 
ments from Mount Sinai” to “pain in the neck.” 


*As it turned out, the migration problem never presented itself. 



CHAPTER 16 


FROM BOSTON TO POUGHKEEPSIE 


One of the big problems in getting together with IBM was the 
time it took to get from Boston to Poughkeepsie. It took the better part of a 
day to drive that distance over poor roads, and it took even longer to take 
the train to New York and then on up to Poughkeepsie from New York 
City. Lincoln owned a fleet of cars, mostly 1950 Plymouth station wag¬ 
ons, which were by then almost worn out. Those of us who traveled to 
Poughkeepsie every week would take these cars, although they were 
uncomfortable and unreliable. I remember one incident when Everett and 
Taylor and I took one of the Ply mouths to Poughkeepsie. I was driving 
and I had a very bad time of it. The next time, instead of taking a 
Plymouth, Everett decided to rent a car. This caused quite a stir with Harris 
Fahnestock, who was then the head of the Administrative Division of 
Lincoln Laboratory, but it did give Everett the opportunity to demonstrate 
the need for better transportation. 

My friendship with Bob Everett grew naturally out of respect for 
his intelligence and his unassuming manner. In his work he had a way of 
seeing problems clearly and going right to the heart of the matter, of 
examining the extremes and identifying the range of alternatives in such a 
way that decisions could be made. Our professional friendship was overta¬ 
ken by a personal friendship during the course of the trips to Poughkeep¬ 
sie, when we would engage in a kind of banter based on the differences in 
our backgrounds. Everett’s father was a successful civil engineer who 
owned his own New York firm which had hydraulic projects in many parts 
of the world, from South America to Poughkeepsie where he had designed 
the water works. Bob had lived in New York and in Florida while he was 
growing up; he had tutors and went to private schools. In contrast, I had 
grown up in North Dakota. My father was a grain buyer and we lived in a 
small town with three or four other families. I walked two miles to school 
to a one-room schoolhouse, and carried my .22 rifle with me and kept it in 
the cloakroom. Going to and from school, I used the rifle to shoot jackrab- 
bits which I later sold for ten cents a hide. 

During our travels to Poughkeepsie, I used to make up stories, 
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some partially founded in fact. I told Bob that I left home to go to a meat 
boner’s school, and that when I left, all the townspeople gathered at the 
railroad station, and the band played as I went off to make my fortune. I 
said I came from Yellow Jump, North Dakota — a fictitious place, but with 
characteristics similar to those of the place I had actually come from. And I 
described the reaction of the people in the town to my career: when I 
graduated from MIT with a master’s degree in engineering, the local paper 
in our town had a small article with the headline, “Local Man Completes 
Electrical Course in the East.” 

When Everett discovered that I was a terrible driver, I pointed 
out that in North Dakota I had never learned curves. In fact I didn’t have to 
learn anything there, because the roads were plain dirt and once you got 
into the track, all you had to do was work the accelerator to get where you 
wanted to go. When he found that my spelling was bad (it seemed to him 
that nobody could be that bad, and that I must have been putting him on), 
he tended to treat it as a lovable eccentricity, rather than as a sign of chronic 
illiteracy. Anyway, the trips cemented our personal friendship. We had fun 
together. 

Later, we began using chartered aircraft. It was not much more 
expensive than driving and it got us to Poughkeepsie in an hour as opposed 
to five or six hours on the road. We got our first taste of air transportation 
when we were stuck in Poughkeepsie without a car, and with no car rentals 
available. A local pilot volunteered to fly us home to Massachusetts in his 
Grumman Goose. We were pleased to see that it had two engines, but this 
complacency soon disappeared when we were told that the plane could not 
fly on just one engine. The fact that there were two engines increased the 
probability that you would go down. However, it was a successful flight, 
and spoiled the Plymouth wagons for us. 

After that, we started flying with a man named Leo Kerivan who 
had a Beechcraft Bonanza, one with a V-shaped combination rudder and 
elevator. Kerivan had just retired from the Navy and was trying to make a 
business out of executive transportation. Our first round trip with Kerivan 
was quite an adventure. Richard Fallows (another engineer from Group 
62) and I had taken the plane to Poughkeepsie. It was a very cold below- 
zero day, and after a short while it became clear that the internal heater 
wasn’t working very well. Kerivan was upset about this as we were his first 
company sponsor, but aside from being quite cold, the trip was good by 
comparison to the automobile alternative. 
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The return trip, however, was a different story. Everett had 
joined Fallows and me in order to make his own evaluation of the service. 
As we passed over Worcester, a grinding noise was heard coming from the 
direction of the engine. Kerivan, already concerned about the sale of his 
services because of the lack of heat, told us the noise was a frozen 
tachometer cable. He explained that the tachometer cable had frozen up 
before, but that he thought he had fixed it. He told Everett to reach down 
under the instrument panel and disconnect the tachometer so it wouldn’t 
annoy us any longer. Everett unfastened his seat belt so he could reach 
under the panel. As he moved forward to do this, his shoulder caught the 
door handle and the door flew open, immediately exhausting the little 
warmth there was in the cabin. The door on the Bonanza is situated in the 
slipstream so that, once opened, the door is held open about six inches. To 
close the door, it is necessary to pull the door back against the slipstream. 
Kerivan tried to appear nonchalant as he reached over Everett and caught 
the leather strap that acted as a door pull, but when he pulled on the strap 
and it broke, so did Kerivan’s composure. He tried once or twice to pull the 
door shut by other things he could grasp on the door but to no avail. 
Meanwhile, the below-zero temperature was chilling us to the bone. 
Finally, Kerivan put down the flaps, slipped the airplane in the direction of 
the open door, and at last was able to get it closed. 

We landed at Hanscom Field, but not without further incident. 
After landing, and as we were about to turn off the main runway, the 
engine stopped and Kerivan wasn’t able to get it started again for several 
tries. He finally did, and he brought us safely up to the terminal. But by 
this time Kerivan was one dejected would-be executive flight service 
person; he must have felt certain he wouldn’t get the job. In spite of that 
first experience, we used his services for a long while afterwards. Later, 
we were able to supplement Kerivan’s services with IBM’s Aero Com¬ 
mander, but only when our travel schedules meshed with IBM’s. Some 
time after that, the Steering Committee at Lincoln decreed that MIT 
personnel could only fly in two-engined aircraft, so at that point we had to 
stop using Kerivan’s Beechcraft Bonanza. One evening leaving 
Poughkeepsie we had two engines, but an inexperienced pilot. As we flew 
over the hills of Connecticut, the visibility declined to the point where we 
could not see the ground. You could look down and see the surface within a 
veiy small radius, but you couldn’t see anything forward or aft. The pilot 
could not seem to get a fix, so he went looking for familiar terrain. I 
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remember trying to help him figure out where he was while we flew over 
Route 128. Finally the plane was within a short distance of Boston’s Logan 
Airport control tower. He could hear the tower, but could not get in touch 
with it. Unlike most pilots, who are trained to be cool, this one was May 
Day prone. After yelling “May Day” into the mike, he finally got their 
attention and was patched into the Boston tower. We ended up circling the 
control tower at Logan for 15 or 20 minutes until traffic lightened up and 
we could be brought in. 

Our need for air transportation continued, however, and finally, 
Lincoln, in cooperation with Wellesley Travel Service, bought a two- 
engine, ten-passenger DeHaviland Dove, which we used for several years. 
Eventually, though, the pilot of the Dove began to complain about skimpy 
maintenance, and on one flight — in fact the last flight — he blew an 
engine on take-off, and that was the end of the Lincoln-sponsored execu¬ 
tive aircraft service. 
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CHAPTER 17 


FEATURES OF THE FSQ-7 


It took IBM only two years from the time it was awarded its first 
production contract in February, 1954 to the time the first production 
system was accepted in its manufacturing test cell. From then, it was only 
two more years until the first production system was declared operational 
at McGuire Air Force Base, New Jersey, in July, 1958. 

As the first real-time control digital computer, the FSQ-7 incor¬ 
porated many innovations which gave it capabilities unparalleled in its 
time, and which broke important ground in computer technology. It used 
49,000 vacuum tubes, weighed 250 tons, and required three megawatts of 
power which was provided by five very large diesel motor generators. 
Heat generated by the computer had to be neutralized by a gigantic air 
conditioning system. The system down time, not counting power supply or 
air conditioning, was approximately four hours per year. 

Far and away the most dramatic innovation for the SAGE com¬ 
puter was the core memory. From the initial 32 x 32 planar array of cores 
incorporated in the memory test computer, the technology grew until the 
final core memory incorporated into the FSQ-7 was a 256 X 256 unit 
(65,536 words). By this time, Lincoln had developed new methods, such 
as automatic core testing and a core plane stringing process, which allowed 
reliable and inexpensive core memories to be manufactured and tested in 
production quantities. The FSQ-7 also incorporated a dual arithmetic 
element which permitted simultaneous processing of both the X and Y 
coordinates of the data, thereby giving the computer greatly increased 
speed. 

The FSQ-7 was also among the first computers to use time¬ 
sharing for real-time control problems. It was among the first to ex¬ 
tensively utilize cathode ray display consoles and light guns to direct 
pertinent information from the screens to the computer. The SAGE com¬ 
puter used the Convair 19-inch Charactron tube for PPI display and the 
five-inch Hughes Typotron for textual display. Digital transmission over 
phone lines, originally developed at CRL, was pursued for the FSQ-7, and 
it was Division 2 that designed the first modems to convert digital data to 
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and from analog data for phone line transmission. Introduced for the 
FSQ-7 was the input/output (I/O) break, or memory cycle stealing, that 
allowed computation to continue during input/output operations. The 
FSQ-7 also incorporated a form of associative memory access: a buffer 
drum in which data from different sources was tagged, thereby allowing 
the computer to select, at a later time, all the information from a particular 
source. The branch and index instruction, developed for the FSQ-7, 
allowed instructions to decrement an index register, test for the end of a 
loop, and branch back to the beginning of the loop. 

From the start, the planners of the SAGE system emphasized 
reliability of components, and it was only through their insistence on 
reliability and their refusal to accept components that did not meet their 
standards that manufacturers began to develop higher quality components. 
Since reliability was such an important feature of the SAGE system, the 
FSQ-7 was the first production computer to incorporate marginal check¬ 
ing, the procedure for continually monitoring the deterioration of vacuum 
tubes, so that deteriorating tubes could be detected before actual failure 
occurred. For the FSQ-7, IBM worked with a contractor to develop a 
machine that would automatically assemble and solder printed circuit 
boards, thus greatly increasing their reliability. There was also a central 
circuit design group for the FSQ-7 which made sure that all CPU circuits 
met design standards based on component tolerances and compatibility 
with marginal checking. 

A major feature to promote reliability was the duplex computer 
scheme, which had one computer operational and the other on standby 
status in case a breakdown or failure occurred. This scheme was substi¬ 
tuted for the arrangement described in TM 20, (the first SAGE system 
proposal) known as the Transition System. The Transition System scheme 
had called for three computers at three separate locations within an air 
sector. Each computer would be capable of carrying the full load. The 
expected operating protocol was that two machines would carry the load 
while the third would be available for routine maintenance and for substi¬ 
tution in the operation. This plan was scrapped because it was too costly. 

In the duplex scheme, two computers were housed in the same 
building. One machine was active, while the standby machine was used 
for diagnosing its own troubles while maintaining readiness to take over. 
This duplex computer plan to attain reliability was rapidly assembled 
by a team of IBM and Lincoln people. Steve Dodd, working with the 
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appropriate IBM personnel, completed a design very quickly, causing 
hardly any delay. The design included a separate drum that was available 
to both computers. The computer carrying the operational load continu¬ 
ously sent critical operational data to the drum. In this way, if the opera¬ 
tional computer crashed, the standby duplex could pick up the essential 
data and carry out the operation. The most complicated part of the design 
was the switch. In concept it was very simple, but in addition to switching 
the CPUs, it had to switch all of the peripherals (mostly the 90 or so display 
consoles) from one computer to the other. 

In 1953, the SAGE project realized the need for support facilities 
and a development environment for the SAGE production system. It was 
also recognized that a pre-production model of the FSQ-7 should be built 
to verify the overall design, including the integration of all peripherals and 
remote inputs. Accordingly, IBM received a contract to build two proto¬ 
type FSQ-7 computers, known as XD-1 and XD-2. A new command and 
control center was constructed at Lincoln Lab in Lexington to house the 
XD-1 and pre-production models of the SAGE consoles. This became the 
nucleus of the Experimental SAGE Sector (ESS), and an expanded number 
of radars, airfields and ground-to-air radios were tied in such that the ESS 
covered most of the New England states and the offshore waters to the 
south and east. The XD-1 also became the computer on which the SAGE 
direction center master program was developed. The XD-2 remained at 
IBM’s plant in Kingston, New York, where it served as the proving ground 
for the computer design itself as well as the facility for developing diag¬ 
nostic hardware and software. IBM also created a training center around 
the XD-2 for Lincoln Lab, RAND/SDC, Western Electric and IBM pro¬ 
grammers and the IBM hardware maintenance personnel. 

During the development of the various SAGE subsystems, there 
was a common misconception that the overwhelming majority of the 
vacuum tubes in the SAGE system resided in the FSQ-7. In fact, almost as 
many vacuum tubes were contained in the radar sites — in the radar itself, 
and in the FST-1 and FST-2 modems that interfaced with the radar. The 
FST-2, for example, had 3,300 vacuum tubes. Each direction center had 
as many as ten radars feeding it, and the aggregate of radar-related vacuum 
tubes was almost as many, and in some cases more, than in the direction 
center computer. 
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CHAPTER 18 


ELECTRONIC WARFARE 


Ihe jamming threat to SAGE was a persistent problem to every¬ 
body, including the Systems Office. It was liberally discussed throughout 
the course of the system design. Many of the schemes that were generated 
were analyzed by the Systems Office. This continuing problem brought 
me into contact with the Countermeasures Group in Division 4. 

The Manual System was extremely vulnerable to all forms of 
jamming. To counter this threat, the SAGE design incorporated anti¬ 
jamming measures at all levels. The basic problem was that it was easy to 
jam the SAGE radars. It was relatively simple for a jammer to radiate 
strong signals at the radar’s frequencies so that at all ranges, there was 
enough energy to swamp any normal radar return. It was, therefore, 
impossible to detect targets in the usual way. Normally, a target appeared 
on the PPI scope as a single blip for each pulse of the radar. The jamming 
signal appeared as a strobe reaching from the center of the PPI picture out 
to the edge of the screen. This solid strobe made it impossible to tell the 
actual location of the jammer on the line. However, when the radars were 
jammed, the strobes could be used to triangulate and fix the position of the 
jammer. The jammer location data could then be used to vector intercep¬ 
tors to take out the source of the jamming. 

Another way of countering the jamming threat was to use the 
height finder radars, which operated at different frequencies than the 
search radars, and to take advantage of their additional power. The height 
finder was slewed in azimuth and sent out a vertically scanning pencil¬ 
shaped beam, which measured the angle from the earth’s surface to the 
aircraft elevation. The height was calculated from this data. 

The design of the radar receivers themselves employed anti¬ 
jamming circuits which, while not able to eliminate the jamming, never¬ 
theless constrained the jammer-induced false alarm rate. Generally, these 
circuits modulated the outgoing signal and looked for the same modulated 
pattern in return. 

Besides the jamming of radar frequencies by means of strong 
signals generated within the frequency range of the radar, the SAGE 
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system would also face the possible use of chaff — a tinsel-like material 
that could be dumped into the atmosphere by incoming enemy aircraft. 
Radar returns from chaff caused the system to report false targets at the 
range and azimuth of the drop. As a countermeasure, Moving Target 
Indicator (MTI) circuitry was incorporated into many of the SAGE radars. 
It operated by discriminating between the relatively high speed of the 
penetrating aircraft, and the lower speed of the windbome chaff. 

Another approach to the jamming problem was the siting of the 
radars themselves to provide double and triple coverage of a target. While 
a determined jammer could normally prevent radar detection at forward 
aspect angles, it was less likely that all radars within range of the target 
would be denied coverage all the time. Radar “bum-through” was more 
likely to occur for those radars having a broadside view of the aircraft and a 
closer range to the aircraft. The beneficial effects of triple radar coverage 
were substantially enhanced by having the radars operate at significantly 
different frequencies (which would require the hostile aircraft to carry 
multiple jammers, ultimately displacing some of the available weapon 
payload). The spreading of radar frequencies across distinct bands, as an 
anti-jamming measure, was to be achieved through the Frequency Diver¬ 
sity (FD) radar program. Although never completed, the program 
involved installation of a family of radars whose frequency bands were 
chosen to cover the entire spectmm used by the ground environments. 

We also took advantage of the fact that jammers were less 
effective in denying radar coverage of our interceptors, because the inter¬ 
ceptors were equipped with a beacon that was interrogated from the ground 
and that radiated a coded response which was much stronger (by several 
orders of magnitude) than the skin return from these interceptors. So, 
although the search radar signal might be jammed, a jammer would require 
considerably more power to swamp out the beacon signal return as it came 
back to the ground antenna. This beacon was a variation on one which was 
used in World War II for Identification, Friend or Foe (IFF). It employed a 
coded pulse pattern that could be used to communicate certain informa¬ 
tion, such as an identity code, to the ground control station along with the 
regenerated return pulse. Thus, although the unidentified and hostile data 
might be missing, friendly aircraft tracks could be followed. 

Work at Lincoln on triangulation of jammers led to investigations 
of a related problem. Triangulating on jammers becomes rapidly more 
difficult as the number of jammers increases, since spurious strobe 
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intersections are formed in locations where there are no jammers. (These 
are commonly referred to as “ghosts,” as distinct from intersections 
associated with actual jammers.) Several approaches to identifying and 
eliminating the spurious intersections, a process known as “deghosting,” 
were tried. 

One deghosting approach used computer processing of the strobe 
intersection data. For example, an intersection could be tracked (provi¬ 
sionally) for a time, to see if the presumed target exhibited reasonable 
flight dynamics. Intersections that moved and accelerated in uncharacter¬ 
istic ways could be considered as ghosts. Several other deghosting 
schemes were proposed. One, by Ramo-Wooldridge, used noise correla¬ 
tion processing that depended on signal correlation and time-of-arrival 
techniques. An experimental system was tested (the AN/TLQ-8), but was 
never deployed as part of SAGE. 

Effort on another implementation of the noise correlation 
approach was initiated at Lincoln by Andrew Bark, head of the Counter¬ 
measures Group, and would be carried forward in the early days of 
MITRE. Andy had a hard time relating his program to thej^eeds of SAGE. 
When I spoke to him about solutions to the jamming problem, he would 
invariably turn the question around from what was needed for SAGE to 
how far you could get with schemes that his group was pursuing. His own 
personal inclination was to spend his effort on the design and fabrication of 
parts for the schemes that interested him. Andy’s noise correlation 
approach was known as the Strobe Intersection Deghoster (SIND). It was 
based on a bistatic correlation system that employed antennas at a pri¬ 
mary site and a remote site, and a computer-based triangulation process 
(JAMTRAC). This deghosting technique was very powerful, but in the 
final analysis cost considerations precluded its implementation in SAGE. 

We tried to test the effectiveness of our anti-jam measures via a 
cooperative program with SAC. SAC provided an experimental control 
group of B-47s which played the role of the enemy. The Countermeasures 
Group, under Andy and his associate, Harry Schecter, helped to design 
broadband jammers of a general kind to be mounted on the B-47s and to be 
included in simulated attacks on the Cape Cod System and later, on the 
Experimental SAGE Subsector. The first attempt at this was to connect a 
Lincoln-designed jammer to an antenna available on the B-47. The effect 
of the antenna pattern was such that it radiated most of the energy down¬ 
ward instead of toward the horizon, so that the effects of the jamming in 
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the experimental trials did not appear to be serious. It took some time to 
come to this conclusion. To make use of the B-47 in the early tests, it was 
necessary to fly the airplane in a slip mode (one wing lower than the other) 
with its belly exposed in the direction of the radars that were being 
jammed. This procedure was proposed to the SAC people, but they were 
reluctant to do it for a variety of reasons. They had preferred to fly (and 
finally did) with the belly toward the jammed antenna by circling in long 
ovals, where there is a natural tendency for the plane to fly with one wing 
lower than the other. In the pursuit of a longer time in this attitude, one of 
the Lincoln people asked the SAC man responsible for providing the 
service why he couldn’t just fly a straight line in a slip mode. The tongue- 
in-cheek response was that with this kind of tilt, the airplane’s battery 
would spill its water. In any case, a new antenna was developed by Andy’s 
group, based on an earlier Radio Research Laboratory design. Test models 
of the antenna were fabricated in Andy’s subterranean laboratory at Lin¬ 
coln’s field station, located on the hill above Lincoln Laboratory. This 
antenna had the proper radiation characteristics to act as an enemy jammer 
and to produce enough jamming so that strong strobes were generated by 
the radars. 

Andy, a very careful experimental researcher who tended to be 
introverted, took no real pleasure in being a supervisor. People who 
worked for him respected his approach, but did not count on him for seeing 
the big picture. He avoided planning and speculation, and proposed con¬ 
crete experiments. He was basically a researcher. Harry Schecter tended to 
front for the organization. He came from AFCRL and shared many of 
Andy’s personality characteristics. The group as a whole tended to be 
introverted and it was difficult for me to assess their work. The people in 
this group, however, seemed generally happy with what they were doing, 
and did not expand their field of view. 

The identification of Lincoln people with the organizations they 
were part of was very strong. It was difficult for people to move from 
group to group. But when this was necessary, they tended to be “loaned” 
for the duration of the project they were moved to. A typical example was 
Gerry Klein, an engineer who was loaned from Andy’s group to Dave 
Israel for Dave’s project in support of the design of the NATO Air Defense 
Ground Environment (NADGE) system. Gerry spent several years on loan 
in Paris before he returned to his “home” group with Andy. 

Another area of concern to Division 4 was the vulnerability to 
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jamming of communication links between SAGE and its interceptors. One 
of the objectives of the SAGE design was to provide an automatic commu¬ 
nication link between the direction centers and the interceptors. The first 
ground-air system employed in SAGE was that used in the Manual Sys¬ 
tem, UHF voice radio, which had omnidirectional antennas both on the 
ground and on the aircraft. Instructions to the interceptors were transmitted 
by voice. This link was quite vulnerable to jamming. The initial approach 
to providing an automatic link was the frequency division data link, in 
which each interceptor aircraft was assigned a unique frequency channel at 
the start of its mission. The pilot tuned his radio to the assigned channel, 
and during the course of the mission the direction center routed guidance 
instructions to individual aircraft by commanding a ground-to-air transmit¬ 
ter to broadcast on the appropriate frequency. 

Later, under the direction of Herb Sherman and Ronnie 
Enticknap, Lincoln developed the time division data link scheme that 
permitted all interceptors to remain tuned to a common frequency channel. 
A guidance message to an interceptor then included a digitally encoded 
address indicating for which aircraft the message was intended. 

The electronic countermeasures work was important in that it 
helped ensure the adequacy of the sensory environment that provided the 
input data to the SAGE computers. Continuing an active involvement in 
the surveillance/countermeasures/counter-countermeasures arena would 
help MITRE maintain first-hand knowledge of threat and counter-threat 
dynamics as these fields evolved. It is interesting to note that as the sensory 
part of the SAGE system was maturing, planning for the systematic 
thinning out of the ground environment (reflecting the increasing emphasis 
on the emerging missile threat) was under way. 
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CHAPTER 19 


DEFINING THE SAGE SYSTEM 


While IBM and Lincoln were learning to structure the process 
of making decisions about the design of the FSQ-7, the Air Force was 
struggling with similar problems in managing the various elements of the 
SAGE system. To facilitate the design of the air defense system, Air 
Defense Command Headquarters set up a special staff group under Colo¬ 
nel Oscar T. Halley, reporting to Major General Frederic H. Smith, Jr., 
Vice Commander of ADC. The function of this group was to work out the 
overall system design and provide a general description of the operational 
employment of the air defense system and its parts — including a defini¬ 
tion of the Air Defense Command divisions, cross-telling and backup 
philosophy, as well as a description of the location of direction and combat 
centers. This ADC special task group negotiated with Lincoln on the 
design of the Transition System. Halley himself had been a backer of the 
system proposed by the University of Michigan’s Willow Run Laborato¬ 
ries, which advocated an air defense system based on their BOMARC 
interceptor. He continued to push that system until the choice of the 
Lincoln system was made at the highest Air Force levels. Once the choice 
was made, Halley’s team saluted smartly and went to work providing 
guidance to the Lincoln system. 

In 1954, Lincoln developed the initial architecture for the Transi¬ 
tion System, described in the TM 20 document. Halley and his ADC team 
then helped Lincoln create the SAGE Operational Plan, informally known 
as the “Red Book,” which outlined the design and deployment of the entire 
SAGE system and established a framework within which each participant 
could find his place. 

In spite of the fact that Halley had favored the Michigan system, 
he brought to the task of preparing the Operational Plan the drive and 
enthusiasm that were sorely needed. He was a good staff officer, and was 
responsible for helping to initiate the SAGE system design. He was a 
worrier. He tended to be a bit vague when it came to definitions of the 
operational design, but this was probably necessary in order to give the 
subsystem designers room as they went about the detailed design. General 
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Smith, to whom Halley reported, was a backer of the SAGE automation 
concept. He took a broader, more philosophical attitude toward the sys¬ 
tem, and expressed his belief that SAGE was a good thing because it would 
accelerate development of this new technology, which, in his view, would 
have significant consequences in applications to civilian as well as military 
problems. Many people likened it to the Air Force KC-135 tanker, which 
was designed to refuel bombers in flight, and its effect on civil aviation up 
through the development of the 707. The 707 evolved out of military 
experience with the KC-135. 

The design of the SAGE system had a profound effect on the Air 
Defense Command, impacting its geographical divisions, its personnel 
requirements, its organization, and its operating procedures. In addition, 
the Air Defense Command, with the encouragement of Lincoln and the Air 
Research and Development Command, decided to establish a wing at 
Hanscom Field. The purpose of this wing, organized about the time the 
Red Book came out, was to provide Lincoln with local advice and approval 
from ADC on the work they were doing on operational specifications. This 
wing, called the 4620th Air Defense Wing, was commanded by Colonel 
Joseph D. Lee. Lee was a feisty, dapper, experienced fighter pilot. He was 
opinionated and expressed his opinions clearly. Lee had spent a number of 
his earlier years on the air defense problem. He had worked with Major 
General Gordon R Saville on the establishment of the first air defense 
command early in the war, and he had accompanied Sir Watson-Watt on 
his tour of the U.S. air defense system during the war. After the war, in his 
assignment to ADC, he interacted with the ADSEC group, and partly 
because of his background, he was assigned at Lincoln to provide input to 
the operational specifications for the computer program. 

The 4620th Wing was structured along the standard Air Force 
organizational lines, having a deputy commander, intelligence and opera¬ 
tions sections, and other common Air Force organizational entities. The 
operational specifications were discussed in open sessions; modifications 
and changes were made in conjunction with various people in the Wing. 
The Lincoln people who were involved in negotiating the operational 
specifications were led by Charles A. Zraket, who would continue as a 
leader of SAGE operational planning throughout the 1950s. 

When Lee first arrived on the scene, I thought he was going to be 
trouble, so I took the opportunity on a trip to Colorado Springs to invite 
him to my hotel room to discuss how I’d like us to work together. Lee 
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confided to me years later that because of that invitation, he had thought I 
was gay, and he came to my room with all his defenses on alert. (When he 
told me this, I chided him by asking why he had come to the room!) I 
remember the careful way that he joined in the conversation. He said he 
had been relieved to find that all I had wanted was an understanding on 
how we would work together. I told him that from my point of view, we 
were both in this job together and that we would see that he was thoroughly 
informed about what we were doing. We would give him veto power, 
although not directive power, over what we did. He appreciated that and he 
and I became good friends. Shortly after the SAGE system became opera¬ 
tional, he resigned from the service, went to work for IBM for six years, 
and then came to MITRE. 

Lee was also famous for the fact that he called the first and only 
air defense alert on the East Coast during World War II. According to Lee, 
an intelligence report from the Navy had indicated that German bombers 
had the range capabilities to hit the East Coast. At that time, there were 
two radars in the system and a large ground observer corps. One of these 
radars was at Montauk Point on the tip of Long Island, and it detected what 
looked like a multi-bomber formation headed for New York City. Based on 
the intelligence report, the Command Center decided an attack was under 
way. When the radar picked up the airplanes heading in the direction the 
intelligence report cited as potential bomb routes, Lee decided that the 
circumstantial evidence was great enough that it was necessary to immedi¬ 
ately send out available tactical aircraft — even though many were not 
equipped for ground control intercept nor had they the appropriate arma¬ 
ment. This caused havoc all up and down the East Coast. After that 
incident, the Army issued the directive that all sightings of airplanes that 
looked threatening would automatically be called friendlies, since the 
havoc of a real bombing would probably not be as great as that caused by 
that alert. Three or four months later, it was determined that the planes 
picked up by the radar were Navy PB4 amphibians, returning from a secret 
mission in Nova Scotia. 

In 1954, the Air Force established an Air Defense Engineering 
Services (ADES) Project Office in New York City, headed by Colonel 
Richard M. Osgood of Air Materiel Command, to carry the main manage¬ 
ment load. Basically, the ADES Project Office had been charged by the 
Air Force to see that the design, construction, and deployment of the 
SAGE system was accomplished in accordance with approved schedules, 
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costs, and specifications. The ADES office had contingents from Air 
Defense Command, Air Materiel Command, and Air Research and Devel¬ 
opment Command. The ADES office was unique in the sense that it was 
the first full-fledged electronics systems project office; prior to this time, 
most of the items slated for SAGE or parts of the air defense system were 
treated as parts of the weapons systems they supported. It was this New 
York office that broke that pattern. 

There were monthly meetings at the ADES Project Office at 220 
Church Street, New York City, where the status of the SAGE system was 
reviewed. These reviews were usually chaired jointly by S.P. “Monk” 
Schwartz of Western Electric and Colonel O.M. Scott, who was Colonel 
Osgood’s deputy. Scott was a thorough, conscientious, big-brother type of 
man, who took a lot of flak from the Lincoln people with great patience, 
even though most of the Lincoln people were younger than he and his 
ADES staff. 

Of all the military people connected with the SAGE project, 
Colonel Albert R. Shiely, Jr. remained with the project longer than any of 
the other colonels with whom we had direct contact. Shiely had the ARDC 
responsibility for the ADES project office when it was first formed. He 
later went to the Pentagon and became the chief spokesman for the SAGE 
upgrading program. For several years, he was the SAGE program officer. 
He then went to Communications Command for a couple of years and 
later, as a major general, became commander of the Electronic Systems 
Division. 
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CHAPTER 20 


GEORGE VALLEY 


The New York ADES Project Office naturally looked to Bell 
Laboratories and Western Electric to provide the working support to 
handle the planning and contracting required to bring this large-scale 
electronics system into being. Bell and Western were prepared for their 
role since they had been working on the Continental Air Defense Survey 
(CADS) project which had as its aim the upgrading of the manual air 
defense system in the U.S. MIT recommended to the Air Force that Bell 
and Western play the prime role in the system engineering and design of 
SAGE. Bell, in turn, recommended that they supply help as they did in the 
CADS project, but they thought Lincoln ought to have the system engi¬ 
neering role. Lincoln, which had been set up as a research and develop¬ 
ment laboratory, did not see its role as architect engineer or large-scale 
system designer. Furthermore, one of the original principles advocated by 
the Air Force as well as by MIT in the establishment of Lincoln Laboratory 
was that, based on the charge to develop a revolutionary air defense 
system, Lincoln ought to have great discretionary powers in defining its 
own program. In practice, however, the notion that Lincoln had discre¬ 
tionary power was not consistent with the desire of the Air Force for a 
responsible, accountable technical organization to be in charge; from the 
beginning, the Air Force, including the ADES Project Office, tried to 
monitor what Lincoln was doing, recommending changes as they saw fit. 

Within Lincoln itself, there was disagreement among three prin¬ 
cipal managers — Director A1 Hill, Associate Director George Valley and 
Division 6 Head Jay Forrester — as to what the SAGE system should be, 
how to organize the development of the design, and who would be in 
charge. The problems generated by the disagreements among Hill, Valley, 
and Forrester only exacerbated the Air Force’s growing fmstration with 
what they saw as Lincoln’s unwillingness to organize itself and support the 
Air Force people who were responsible for getting the job done. Further, 
the interactions between Hill and Valley and the Air Force led to frustra¬ 
tion on the part of ARDC Headquarters, and involved the ARDC com¬ 
mander, Lieutenant General Thomas S. Power. Power wanted the 
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connection with Lincoln, as it would help solve the Air Force’s need for 
guidance, but he and his deputies saw chaos when looking at what was 
happening. It was impossible for them to identify who was in charge. 
Power’s reaction was to pressure MIT to put somebody in charge who 
could marshall Lincoln’s talent. 

These problems and the divergence of opinion on the matter of 
Lincoln’s independence grew and festered until they contributed to the 
resignation of A1 Hill, who left to join the new Institute for Defense 
Analyses (IDA), and later to the resignation of George Valley. In the 
reorganization that followed Hill’s departure to IDA, his MIT manage¬ 
ment, led by President Killian and retired Navy Admiral Edward L. 
Cochrane (then Vice President for Industrial and Governmental Relations 
at MIT), chose not to name George Valley as director but appointed 
instead Dr. Marshall G. Holloway, who had been working in the atomic 
energy field. The Air Force hoped that this change of directorship would 
make it possible for them to get what they wanted out of Lincoln. In my 
opinion, Holloway was never quite accepted by the Lincoln staff, nor did 
he make SAGE a priority program, so he was really unable to deliver to the 
expectations of the Air Force. The tension continued to increase until the 
disagreement between General Power and Holloway was becoming obvi¬ 
ous. The rumors were that it had gotten so bad that Power would not speak 
to Holloway. 

General Power kept in touch with the various elements of ARDC 
through a series of “Commander’s Conferences,” which were held at the 
different centers under his command. These conferences took up the 
problems of the particular center during the day, and were topped off with 
a party during the evening. The entertainment at these parties often 
included impromptu skits. Many of the Air Force people I knew reported 
on one of these skits, which satirized the situation between the Air Force 
and Lincoln. The ARDC Headquarters staff, taking the parts of Lincoln 
managers, ridiculed the situation. In effect, they played prima donna roles, 
not taking orders from anybody but demanding buckets of money. 

Holloway, under the circumstances, could not accommodate the 
Air Force, and this, among other things, eventually led to his departure. 
As a consequence of all this, Valley, as associate director, became the 
chief negotiator. By that time, as a way of dealing with the problem, the 
Air Force had assigned the responsibility for the design of the air defense 
system to the Air Force Cambridge Research Laboratory, and they 
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assigned Lieutenant Colonel Ralph S. LaMontagne to head a Lincoln 
Project Office which was set up to oversee Lincoln Laboratory. Needless 
to say, LaMontagne had a hard row to hoe. He was caught between a very 
strong head of ARDC, General Power, and an equally strong and obstinate 
Lincoln management. LaMontagne continuously complained about his 
ulcer — which seemed to be developing at great speed in his negotiations 
with Valley. Valley would not swerve from the original intent in the charter 
of Lincoln Laboratory and insisted upon the lead role in designing the 
system. 

In spite of the fact that I had been with Lincoln from the begin¬ 
ning, I didn’t get to know Valley very well. From my perspective, he had 
performed brilliantly on the ADSEC group and on the Charles Study, but 
he seemed to be an independent worker and he did not communicate freely 
with me. He once told us, apparently in jest, that his idea of a good leader 
is a man who finds out which way people are going and then runs up ahead 
of them. One of his characterizations was of a scientist as the kind of man 
who would run around with an unwrapped sandwich in his pocket. With 
his tweed jacket with leather patches on the elbows and his generally 
rumpled and preoccupied look, Valley seemed to fit that characterization. 
He was a chronic gum-chewer, and relied heavily on cigars in social 
situations. He was of above-average height, a little more than average 
weight, well built, with dark hair and bushy eyebrows. His eyes were his 
most outstanding physical characteristic — they were unusually pale, like 
those of a timberwolf, and gave me an impression of cunning and 
unpredictability. 

The military people and others with whom Valley had a lot of 
interaction seemed to either love him or hate him. In any case, people were 
not neutral in their relationships with him. Even those closest to him never 
seemed privy to his complete confidence. He consciously or subcon¬ 
sciously projected an image of himself as aloof, distant, and superior. One 
was never quite sure whether he was candid in the things he said. In spite of 
these things, he was trusted by those who worked directly for him and by 
most of the more senior military officers, whom he needed for backing. I 
was impressed by Valley’s practical approach to the big system problem of 
SAGE and always regretted that I didn’t know him better and that most of 
my encounters with him elicited a defensive mood, causing me to back off 
because of my own self-doubt. 

As Lincoln Laboratory had evolved and as A1 Hill assumed the 
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directorship, it had appeared that Hill and Valley were working at cross 
purposes. I suppose that Valley felt he should have been made director 
because of his contributions to the ADSEC study and to the laying of the 
groundwork for SAGE. It seemed to me as though he often felt that there 
was some sort of conspiracy he had to deal with, and his method of dealing 
struck me as indirect. I think he found Forrester, who was inner-directed, a 
difficult subordinate to lead; in fact, there seemed to be a competition 
going on between them as to who was the intellectual “father” of the 
SAGE system. In retrospect, it is clear that Valley was a driving force who 
could claim a large part of the credit for generating and negotiating the 
creation of the Lincoln Laboratory and the SAGE system. It seemed to me 
that he ought to have been given more direct responsibility earlier on; if he 
had, perhaps some of the conflicts that became evident well into the 
program would have been avoided, or resolved sooner. Among Division 6 
personnel Valley was held in high regard, and there was always a residual 
feeling of appreciation for his having drawn us into Lincoln Laboratory to 
continue our air defense work. 

Although CRL was now officially in the chain, there was no way 
it could accomplish its mission without the acquiescence of the Lincoln 
management. The conflict between LaMontagne and Valley continued. It 
reached the point at which the New York Project Office, in the person of 
Colonel Shiely, had to intervene. He made sure that the Lincoln-generated 
technical information reports went directly to the New York office, where 
they became directive in technical matters to LaMontagne’s CRL Lincoln 
Project Office. 
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CHAPTER 21 


MA BELL 


I he Bell System held a unique position among the SAGE con¬ 
tractors — they had the greatest experience with integrated ground elec¬ 
tronics. With their renowned Bell Laboratories, they had the most 
thorough laboratory support, with proven performance. 

In most instances, the contracting was handled through Western 
Electric. Western Electric, in turn, contracted for specialized help with 
Bell Labs and AT&T. The Bell/Western people were used to managing 
large projects, and their support to ADES numbered in the hundreds of 
people. They had been introduced to upgrading the air defense system in 
the CADS program. For SAGE, they increased their responsibilities by 
acting as a general contractor on a site-by-site basis. They carried the 
baseline components list and that part of the system design which fell into 
the support category, such as the building that housed the direction center, 
the prime power system, the air conditioning, administrative support, 
office furniture, internal telephone, etc. They also maintained the master 
schedule on which they tracked the progress of all the participants. In 
addition, they were responsible for the acceptance test methods and the 
evaluation of the system. Most of the Bell people took pride in the 
organization and were aware of its uniqueness. 

Since Bell did not compete openly for work, and because 
demand for their unique capabilities was always greater than the supply, 
Bell/Westem could sit back and allow themselves to be pursued by people 
who wanted to get things done on a large scale in electronics. For the 
projects they wanted to do, they needed only to let themselves be wooed by 
those people having the jobs. And, when they accepted a job, it was almost 
as if they were doing their customer a favor. 

This attitude permeated the company. It had an effect similar to 
the MIT effect, wherein a lot of authority was assumed based on past 
performance and reputation of the company (and not necessarily on any 
single individual’s past performance and reputation). Part of the mystique 
of the organization was that it contained a large number of Nobel laureates 
and other prize-winning performers. It was almost as if these people, 
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somehow, were a part of the package that you got when you contracted 
with them. The actual people who worked on the SAGE job were very 
good. At Western, S.P. “Monk” Schwartz stood out. 

Monk was clearly the outstanding contributor. He was level¬ 
headed, pragmatic, and applied common-sense solutions to problems as 
they arose. He was a pleasant looking, well-built, energetic man. I remem¬ 
ber him as wearing tan clothes consistently. Monk clearly had the respect 
of all the people who worked with him and around him. It came as no 
surprise later when he was picked to become president of Sandia Corpora¬ 
tion, Western’s contribution to the atomic weapon business. 

At one point in the program, Western needed complete plans for 
an alternate NORAD command operation center, to be located at Richards- 
Gebaur Air Force Base in Kansas City, Missouri. One of the additions to 
Lincoln’s responsibilities was the design responsibility for this center. I 
assigned Lawrence R. Jeffery the task of preparing the essential specifica¬ 
tions. Larry and his people turned out the necessary specification in less 
than a week. This caught Monk’s attention. He was dumbfounded by the 
speed of our response, and was very complimentary. He remarked that the 
Lincoln staff was so young, and after hearing that the document had been 
produced by an overnight push, he said that the Bell System was a mature 
organization that wouldn’t give its younger staff such administrative 
responsibility, and that it required the stamina of youth to do what Larry 
had done. He also remarked that the Lincoln people were too young to 
know that they couldn’t do what they did, and then he contrasted the 
people in the Bell System to Lincoln and pointed out (in jest) that serious 
responsibility at Bell was given only to people over 40. However, there 
was more than “youth” involved here. Larry was unusual, and, by coinci¬ 
dence, had worked at American Television. He had also learned electron¬ 
ics in the Navy in the electronic technician’s program. He hadn’t gone to 
college, but was teaching advanced mathematics courses at American 
Television. In the early 1950s, he entered the University of Chicago, and 
in two years qualified for a master’s degree. Larry also had the ability to 
talk backwards — he could take a paragraph, read it aloud, and then say the 
paragraph in reverse order and the words in reversed sound. 

Monk was backed up by a large number of Western Electric and 
Bell Labs people. Their duties included keeping a master schedule and 
managing phasing group meetings, at which all the participants (contrac¬ 
tors) gave progress reports on their parts of the job. These phasing group 
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meetings were designed to lay out the situation clearly, so that the Air 
Force could make informed choices. The products of the meetings were 
modifications to the contracts held by the associate contractors. The 
participants also carried on with activities showing the financial status of 
the whole program. One of the key Western men was Robert Bright, who 
was a kind of expediter, motivated by the discrepancies found at the 
phasing group meetings. When some incongruity was uncovered in the 
phasing group meetings, Bright would tear into it like a bulldog and carry 
on mini-phasing group meetings with the parties most responsible for the 
trouble. Bob was a short man with a large head; he was self-confident and 
energetic. His activities were fueled by anything that had an effect on the 
SAGE schedule. It was a pleasure to solve the problems or do anything to 
get Bob off your back. 

When we began thinking about integrating SAGE with the weap¬ 
ons systems it was to control, Bob Everett and I met with Bob Bright 
periodically. At these meetings, Bright generally brought Clair W. “Hap” 
Halligan with him. Halligan was director of military engineering at Bell 
Labs and would later become the first president of The MITRE Corpora¬ 
tion. Halligan had a good reputation among the SAGE participants. He 
was personable and flexible, and generally supportive of those of us who 
were charged with the responsibility of the SAGE design. His judgments 
were pragmatic — he did not like confrontation and would compromise 
when he saw no chance for holding to a principle. He brought with him to 
these meetings his ability to engage Bell/Westem expertise. He was used 
to working within the power structure of the Bell System, and seemed to 
feel unsure of himself outside of that context. This was to become a factor 
in the development of the early MITRE operations. 

In addition to Bell’s contractual responsibilities, MIT leaned on 
the Bell System for their judgments about the overall program and about 
the quality of Lincoln’s performance; it was important to MIT manage¬ 
ment to have the backing of the Bell System’s opinion leaders. This had its 
dark side as well, because if the judgment of Lincoln’s work was negative, 
it was difficult for us to overcome it. The whole program reacted to these 
negative opinions, which tended to affect the design decisions in awkward 
ways. For example, in one such instance, a paper was written by Bell 
stating that the data rate from the radars in the system was too low and 
suggesting ways of getting higher data rates. None of the suggestions 
helped materially, but the focus changed from solving the problem to 
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pleasing the individuals who had come to that conclusion. But in spite of 
this aspect, the Bell-Lincoln connection worked quite well. 

The network of phone lines between the radars and the direction 
centers, the cross-telling lines and the lines to headquarters (NORAD) 
constituted the first major digital network in the country. On the Lincoln 
end, this part of the design and the negotiations concerning it were headed 
by Ronnie Enticknap. Ronnie, a good-natured, articulate, well organized 
man, carried on the negotiations with AT&T in an exemplary manner. I 
often felt that his British accent increased the authenticity and importance 
of his pronouncements, even on trivial issues. 
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CHAPTER 22 


GROUP 61 


I stayed with the Systems Office until 1955, at which time I was 
transferred to become Bob Wieser’s associate group leader in Group 61. 
This group had charge of the Cape Cod System, and was to be assigned the 
SAGE computer program. Heading the Systems Office had been unusually 
educational. By the time of my transfer, the Systems Office had processed 
most of the designs of the original SAGE system, and I knew the system as 
well as anyone. 

When I left the Systems Office, it continued on under Benham E. 
Morriss and was called the Design Control Office. Ben had gone to 
military school and had always been a clean-featured, friendly, capable 
member of the staff. Eventually he became head of the group that installed 
the Lincoln version of the master computer program at the first three 
SAGE sites. Ben was well-organized and had good management skills. He 
had a master’s degree from MIT’s Sloan School of Management. He did a 
very fine job with the Systems Office while he had it, and an excellent job 
in managing the installation of the program at the sites. In 1958, he would 
choose to go with SDC rather than remain with Lincoln or spin off to 
MITRE. He gave as one of his reasons his feeling that I was too dominant, 
and he didn’t think he could get along with me. Before this, I had felt that 
we had a good rapport, and I was surprised and saddened by his remarks. 

At the time I joined Group 61, the design of the FSQ-7 was pretty 
well set, and attention was turning to the computer programming that had 
to be done. I joined the group with a certain amount of apprehension. I had 
not been in the programming business nor did I know a great deal about it; 
furthermore, the group of people working for Wieser who did know about 
it had already arranged, to a large extent, the organization of the program. 
The key people were David R. Israel, Charles A. Zraket, Herbert D. 
Benington, Robert Walquist, Walter S. Attridge, and Jack A. Amow. 
Israel and Zraket concentrated on operational specifications, while 
Amo\v, Attridge, Benington and Walquist concentrated on the “program¬ 
ming” of the system. I was apparently selected to help Wieser because of 
my ability to draw projects and people together and because I knew the 
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FSQ-7 machine better than most. As soon as I had joined Wieser’s group 
and had reviewed the status of the computer program, I became alarmed by 
the lack of planning on the program. As a consequence, most of my efforts 
were devoted to resolving the schedule problems. 

I found Wieser to be a delightful person to know. He was 
extremely witty and quick and was a master of memorable one-liners. He 
tended toward the ironic and bordered on the cynical, but I became his 
friend and enjoyed his company very much. Wieser wore a hearing aid that 
gave him several advantages: he could turn off conversations that were 
boring; he could turn off the noise at night. But by far the most unusual 
ability his hearing aid brought to him was recalled by some of the members 
of his group when they were to visit an operational radar site for a live 
demonstration. Wieser said there was no need to hurry to the demonstra¬ 
tion, because he knew the radar wasn’t working. His group couldn’t figure 
out how he could have known it, until he revealed that his hearing aid 
could pick up radar sync pulses. 
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CHAPTER 23 


THE RAND CORPORATION AND SDC 


■he assignment of the programming tasks to the various organi¬ 
zations involved in the development of the SAGE program was fairly 
straightforward — except for the assignment of the master operational 
program. It was clear that the machine diagnostic program ought to be 
done by IBM, and Bell and Western Electric ought to do the test and 
evaluation programs. Lincoln assumed a responsibility to create the first 
operational master program. But the inevitable evolutionary changes of 
that program, as well as the program maintenance at the site, required a 
commitment MIT was unwilling to make. Lincoln felt that Bell and 
Western ought to take this responsibility, but it was Colonel Tom Halley 
and the ADC people who suggested that the RAND Corporation take on 
this job. Part of the reason for this was that RAND was already under 
contract to ADC for operational training in the Manual System. The 
training had grown out of a series of human factors experiments proposed 
by Dr. John L. Kennedy at RAND. 

Also involved in the project were Dr. William C. Biel and Dr. 
Robert L. Chapman. They had set up a test facility at which they simulated 
the job of the operators working at PPI scopes in the Manual System. The 
purpose of the simulated test facility was to determine the value of simu¬ 
lated training in control situations where the inputs were known and the 
operators could be debriefed about their errors immediately after they were 
made. It began as a crude simulation — the scopes were simulated by 
wooden consoles with round holes the size of PPI scopes, and a continuous 
sheet of computer printout paper presented operators with a picture similar 
to what would be represented at a manual site — but the results were 
surprising. These experiments with volunteer operators proved them to be 
much more proficient than might have been expected. ADC became 
interested in this experiment and sent some operators to RAND to partici¬ 
pate in these tests, and it was demonstrated that those operators who were 
doing poorly in the field did well at the simulated facility. ADC attributed 
this to the training setup, and as a consequence, ADC contracted for the 
System Training Program (STP). With Air Force support, STP became a 
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highly sophisticated training program, using electronic devices to simulate 
radar signals. Through STP, simulated radar data from RAND could be 
entered at any site and the whole manual direction center could be exer¬ 
cised, corrected and trained. 

One of the features of SAGE was the extensive use of simulation 
programs and operational testing aids; the STP program created simulated 
airplanes by signals entered into the system at the radar sites. These and 
other simulated inputs were integrated so as to create a simulated scenario 
against which the operators could direct intercepts and be scored on their 
performance. Dave Israel pushed for a battle simulation program within 
the direction center and internal to the FSQ-7. In this system, an internal 
program simulated airplane signals that could be mixed with live signals 
generated by real aircraft. The simulation was an extremely useful feature 
and was coordinated with the STP design. 

In the process of generating these training materials, RAND 
relied heavily on their computer division for the printouts that acted as the 
training materials. In order to do this simulation, it was necessary for the 
computer division to understand the specifics of the air defense process. 
When an organization was being sought to take on the task of operational 
programming. Colonel Halley and others brought to the attention of the 
ADES Project Office RAND’s familiarity with the air defense problem. By 
this time RAND had set up a systems training division under William Biel 
and Melvin O. Kappler, and was approached by the Air Force to determine 
whether or not they could take on the operational programming job for 
SAGE. 

Wieser and I met with those people at RAND who would be 
likely to assume responsibility for the SAGE master programming job — 
M. O. Kappler, Wesley S. Melahn, Toby Oxtoby, and John D. Madden. 
Kappler led the group; he was an outspoken, dynamic, and aggressive 
member of RAND’s training division and former member of the engineer¬ 
ing division. Wes Melahn and Don Madden were from the mathematics 
division; Oxtoby was from the system training division. It was clear to 
Wieser and me that Kappler was an entrepreneur who wanted very much to 
do this job; and by the middle of 1955, there was already talk of splitting 
off that section of RAND to provide systems training material and com¬ 
puter programs for ADC. This spin-off came to be known as the System 
Development Corporation (SDC). 

In these discussions, we came to the conclusion that RAND 
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would aid Lincoln in producing the master program and in installing it at 
the first three SAGE sites (McGuire, Stewart, and Hancock), as well as in 
preparing the first program for the combat center at Headquarters, 26th Air 
Division at Hancock Air Force Base in Syracuse. It was agreed that Group 
61 would use RAND programmers, who were destined to be part of a 
follow-on RAND/SDC job to prepare programs for the fourth and subse¬ 
quent sites. 

Wes Melahn, who was later to become president of SDC, was 
chosen as the principal RAND technical person at Lincoln. I shared the 
responsibility with him for transferring the operational program from 
Lincoln to SDC. Wes was a quiet, unassuming mathematician who had 
worked in Howard Aiken’s laboratory before joining RAND. He was a 
good analyst, and brought to the project his considerable practical knowl¬ 
edge about the programming business and what it took to produce pro¬ 
grams. Since the FSQ-7 XD-1 machine was located at Lincoln Laboratory, 
RAND personnel were provided housing by the Air Force in the specially 
built Butler buildings adjacent to the laboratory. 
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(Top) The elements of SAGE. 

(Bottom) A map of the Cape Cod System, 
showing principal facilities 
and locations. 









(Top) George Valley, “father” of SAGE. 

(Bottom) Al Hill as director of MIT Research 
Laboratory of Electronics; he later became second 
director of Lincoln Laboratory. 





(Left to right) Pat Youtz, Steve Dodd and Jay Forrester 
in the Digital Computer Laboratory tube shop. 




Jack Harrington (top), Paul Rosen (lower left) and 
Ernie Bivans of Division 2, whose data transmission work 
made the SAGE network possible. 






(Left) Thomas J. Watson, Sr., the thinker’s thinker. 

(Right) Jay Forrester and his invention, magnetic core 
random access memory. 














(Top) John F. Jacobs. 

(Bottom) Bob Everett, “architect” of the 
SAGE system. 






(Top) Carl Overhage, fourth director of Lincoln Laboratory. 

(Bottom) Jerry Freedman (left) and Bob Naka of 
Lincoln’s Division 4, Radar Systems. 





(Top) Major General Albert R. Shiely, Jr., 
sixth commander, Electronic Systems Division; 
primary Air Force technical man on SAGE. 

(Bottom) Lieutenant Colonel Ralph S. LaMontagne, 
Air Force project officer for Lincoln Laboratory. 





(Top) Colonel J.D. Lee, commander, 4620th 
Air Defense Wing; coordinated SAGE operational specs. 

(Bottom) Colonel Oscar T. “Tom” Halley, ADC, 
Operational Plan manager. 





Forrester’s farewell party (I. to r.): Bob Wieser, Bob Everett, 
Jay Forrester, Norm Taylor. 








Some Division 6 group leaders (clockwise from upper left): 
Gus O’Brien, Dave Brown, Ben Morriss, Jack Arnow. 






(Top) Charlie Zraket, leader in SAGE system planning 
and operational specs. 


(Bottom) Dave Israel, a SAGE system designer 
and the air traffic control expert. 





(Top) Monk Schwartz, Western Electric’s top man on SAGE. 

(Bottom) M.O. Kappler, 
president, System Development Corporation. 



(Top) Brigadier General Arthur C. “Sailor” Agan, 
commander of the first SAGE air division. 

(Bottom) Ed Rich (left) and Charlie Grandy, Experimental 
SAGE Subsector shakedown test managers. 



(Top) Jim Croke, director of BOMARC test 
and evaluation. 


(Bottom) Ken McVicar, master program installer. 




(Top) Jim Killian, MIT president at beginning 
of SAGE project. 

(Lower left) Jim McCormack, MIT vice president; 
negotiated establishment of MITRE. 


(Lower right) Hap Halligan, first president of MITRE. 





(Left to right): Hap Halligan; Major General 
Kenneth Bergquist, commander, ADSID; 
Lieutenant General Bernard Schriever, 
commander, ARDC. 




(Top) General Thomas Power, 
commander, Air Research and Development Command; 
later, commander, Strategic Air Command. 

(Bottom) Gordon Thayer of AT&T; director, Winter Study. 


CHAPTER 24 


GENESIS OF COMPUTER PROGRAMMING IN SAGE 


In the development of any new technology, the distinction 
between state of the art and state of the craft must be made. In the computer 
field, at this time, the state of the art was advancing rapidly, with techno¬ 
logical innovations and new products coming at a fast pace. The state of 
the craft, on the other hand, was progressing much more slowly. Although 
computer developers often exchanged general ideas about the architecture 
of computers, there was no recognized need and hence little agreement 
upon standardization for circuits, order codes, speed of operation, input/ 
output protocols, and other technological components or features. There 
had yet to be developed an infrastructure that would make possible the 
transfer of new ideas and new developments from one organization to 
another. 

With Whirlwind I, however, some parts of an infrastructure were 
already under development. For Whirlwind, it had been necessary to 
build, from scratch, all test equipment — gates, pulse circuits, flip-flops, 
and other logical elements. Harry Kenosian, a former Digital Computer 
Laboratory staff member who transferred to Burroughs, thought he saw a 
business in these test modules and began to market them. These test 
modules were one of the first examples of ready-made computer test 
components. 

The infrastructure became more established by the time of the 
FSQ-7. Ken Olsen and others had designed a line of modular testware that 
could test computer parts as they were developed. This modular testware 
was used in the memory test computer, and it was a variation of this 
testware that would become the basis for the original product line of the 
Digital Equipment Corporation which Olsen, his brother Stanley, and 
Harlan Anderson began in August, 1957. 

What was true for the hardware was also true for the software: 
everything, initially, had to be done from scratch. Each of the users of the 
Whirlwind computer (and of other computers of the time) was faced with a 
bare-bones machine — a machine that responded only to numerals in 
binary code. This meant that users had to be familiar with binary code, and 
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a great deal of time was spent translating from alphanumeric code into 
binary code and vice versa. Most of the Lincoln programmers had their 
first programming experience on the 32-register toggle switch memory. 
There was also an MIT course on digital computer programming taught by 
W. Gordon Welchman, but basically, the early programmers had to learn 
programming techniques through experience. This was the state-of-the- 
programming-art through 1950 at the DCL. 

Initially there were two major users of Whirlwind — a mathemat¬ 
ics group under Charles W. Adams, and the air defense group under Bob 
Wieser. As the time for creating the software approached, almost everyone 
thought there ought to be programs that would translate automatically from 
alphanumeric code into binary code, making it easier for others to use and 
to program the machine. Thus were bom the first assembler programs at 
the DCL. 

The assembler was only one of many utility programs designed 
to simplify the preparation and operation of the program. The Comprehen¬ 
sive System of Service Routines (CSSR) was devised in 1952, and made 
possible floating point calculation in an interpretive language permitting 
the much larger word lengths required by scientific project work. CSSR 
included subroutine libraries of interpretive programs to simplify access to 
peripherals and to permit direct use of decimal notation. These utility 
programs were shaped, initially, by the needs of Charlie Adams’ mathe¬ 
matics group to simplify the programming task, by the needs of the air 
defense group for an integrated system program, and, because of small 
high-speed memory capacity, by the need to do coding efficiently. As 
SAGE came into being, the new Lincoln Utility System was planned to 
meet both the need to develop a very large computer program which would 
be worked on in sections by inexperienced people, and by the need for an 
operational program which could evolve as more was learned about the 
whole system. 

Development of the Lincoln Utility System was initially the 
largest programming task and it was also the most controversial. The 
Utility System consisted of a set of programs that facilitated the task of 
programming, and there was a great deal of debate as to whether or not to 
invest time and effort in developing these tools at the expense of immedi¬ 
ate progress in the development of the operational programs. We took the 
risk and forged ahead with the Utility System. 

The “COMPOOL” (Communication Pool) was a pivotal design 
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feature that greatly simplified the task of programmers. This COMPOOL 
centralized data base descriptors shared by all programmers and allowed 
them to symbolically specify the data required without having to know its 
exact value or location. The initial assembler concept from Whirlwind was 
discarded in favor of a much more sophisticated compiler by the time of 
SAGE. The compiler for SAGE took on many of the features of CSSR, 
containing symbolic, floating and relative addresses which allowed mem¬ 
ory locations to be assigned either by the programmer or automatically, 
based on information in the COMPOOL. 

By the latter part of 1955, the Lincoln Utility System for SAGE 
had grown to about 40,000 instructions supporting an operating program 
of nearly 100,000 instructions. Programs were developed to load informa¬ 
tion into the machine as well as to print out the contents of the memory and 
to format the printout on a page or a scope. A “checker” program was 
developed which made it possible for a person to test his program within 
the machine, thus allowing inexperienced programmers to take part in the 
process. 

When I became associate group leader of Group 61, it took me 
some time to gain the confidence of those people who had been program¬ 
ming for the Cape Cod System, especially those responsible for the 
program, since they knew I hadn’t worked as a programmer myself. But I 
had studied the process and I had done some practice programs. I had used 
the statistics they had gathered to work on the FSQ-7 order code and to 
contribute to the justification of the fast adder design. Herb Benington and 
Jack Amow had the responsibility for formulating the program specifica¬ 
tions and for the actual programming. 

Herb Benington became the architect of the Lincoln Utility 
System. It was largely due to his work that the COMPOOL feature of the 
Utility System was added to the package. He was tall, high-strung, ego¬ 
centric and wore a butch haircut . Herb was very intelligent and had taken 
time off from MIT to be a Rhodes Scholar, spending a year or so in 
England before joining us in the big push for the SAGE program. He 
tended to be an independent worker. In my opinion, his complex and 
contradictory personality made it hard to get new people to work with him, 
except for those who met his high standards and those who wanted to learn 
a great deal about the programming process. When I gave him an assign¬ 
ment, he would more often than not find some reason, sometimes justified, 
for not doing it my way, and would end up changing the problem I was 
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trying to solve. He alienated many people, including me, by his constant 
use of put-downs. These put-downs often took the form of anecdotes he 
would weave into the conversation in which he associated himself with the 
smartest and most powerful people. I was never sure whether he did this 
deliberately or not. I didn’t contribute as much to the art as he did, and I 
don’t think I ever convinced him of the fact that I knew how to run the 
programming business. I was not able to change his opinion before he 
joined SDC. He was later to become a supergrade member of the Depart¬ 
ment of Defense, and still later, a vice president of MITRE. 

Jack Amow had a big hand in programming Whirlwind for the 
Cape Cod System. He was a short, friendly, bright man whom I met at 
parties that he and his bachelor friends threw from time to time, and to 
which they would invite a variety of Lincoln people. He was always 
friendly and entertaining, but we always seemed to be on different wave¬ 
lengths. I tried to analyze why it was difficult to communicate with Jack, 
and it seems to me that he assumed knowledge that his listeners did not 
have and he did not provide neccessary background to ensure the transfer 
of information. He was a nice fellow to work with and was willing to invest 
the time in helping you understand, if he could. He chose to stay with 
Lincoln when Division 6 split off to become MITRE, and later became a 
very successful entrepreneur. He founded two companies: Interactive Data 
Corporation, and Advantage Systems, Inc. 

Although the operational program was large and complex and 
drew most of the attention of the programming group, it was not the largest 
SAGE programming task. The problem of analysis of system performance 
was facilitated by a comprehensive series of recording and data reduction 
programs that distilled the essence of the activities during the operations. 
Most of these programs were created under the direction of Edward L. 
Lafferty, who had been hired during the big push for programmers. 

The recording programs recorded the operational data mainly 
from processed track information as it was manipulated by the operational 
program. This data was recorded as the operational program performed its 
calculations on the real track data. As the operational calculations, such as 
tracking equations, proceeded, the recording programs were instructed to 
pick the numbers that were important in determining whether the opera¬ 
tional system did what was expected of it. It was impossible to process the 
raw data manually because of the sheer volume recorded during the system 
operation. The data reduction programs made this possible. Ed Lafferty 
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estimated that the data reduction programs, altogether, required well over 
a million words of instruction code. Ed and the data reduction group added 
their own innovation to the process by incorporating the COMPOOL 
concept into the newly available higher-order language, FORTRAN. 
Called FAST (for FORTRAN Automatic Symbol Transfer), their new 
language enabled the one million lines of code to be quickly processed. Ed 
Lafferty was one of the programmers we hired in a special category of 
people who were destined to join the new support group for ADSID. He 
spent the better part of his career on data reduction problems in support of 
SAGE and later in support of a large number of computer-based systems. 
Lafferty was a reliable craftsman of the programming business. He was 
light-hearted and personable. 

The data reduction area was a good training ground for a large 
number of programmers who were instrumental in the successful comple¬ 
tion of the SAGE system program. Utility and operations programs were 
developed, and there was a drive to standardize languages, in the hope that 
this would simplify the production process. A number of ideas were put 
forward about standardizing languages used in military operations, which 
caught the attention of one of the RAND programmers, Jules Schwartz. 
Jules was one of the programmers who had been hired from RAND to 
carry on the programming tasks after Lincoln bowed out. He had been 
working on the utility program, and dedicated himself to creating a stan¬ 
dard programming language, and, in fact, he did eventually develop a 
language that became the standard for military computers — JOVIAL, for 
Jules’ Own Version of the International Algorithmic Language. 

As the SAGE design progressed, the demand for computer sup¬ 
port to programs in Divisions 6 and 2 increased. Early in the fifties, 
Division 6 became hooked on the use of computers for support of many 
kinds. At first, there was only the Whirlwind computer to provide that 
support. Whirlwind was used in the development of the operating program 
for the Cape Cod System, and also for the associated utility and data 
reduction programs. Later, the memory test computer absorbed some 
of the load, and the use of the XD-1, one of the two prototypes of the 
AN/FSQ-7, also contributed. 

Even after MITRE was formed some years later, the progression 
of upgrading the support computers was still a necessity, and the latter part 
of this progression would go well beyond the point at which MITRE 
had taken over and SAGE was completed. Because of the demands for 
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computer time being made on the available facilities, first Lincoln and 
later MITRE concluded that they should buy or lease commercial 
machines to provide centralized computer support to the projects. Lincoln 
decided to lease an IBM 704, which was IBM’s first commercial machine 
to feature a random-access core memory. Although frought with friction 
and frustration, this centralization of computer support proved to be a boon 
to the projects. The 704 immediately found use throughout Division 6, and 
it replaced some of the need for Whirlwind to serve as a machine for 
evaluation and design support. 

James H. Burrows, a programmer in my division who had gradu¬ 
ated from West Point but who had chosen not to stay in the Army, evolved 
as the central figure in the management of the centralized computer sup¬ 
port facilities both at Lincoln and then MITRE. We tried to keep up with 
the computers that were available on the commercial market, replacing 
one IBM model with the next, and we upgraded the central computer until 
our policy (by this time, MITRE’s) led us to buy the last of the IBM 700 
series machines, the 7030, aptly called the STRETCH. This “ultimate” 
machine was the first IBM computer offered for sale instead of lease. 

Jim Burrows was prematurely grey and of stocky build. I remem¬ 
ber him as always being on some diet or another. It was his responsibility 
to maintain an efficient configuration of centralized computers. Although 
we had been in the computer software business for many years, we 
suffered from an Air Force perception that we were mediocre in technol¬ 
ogy. Much of Burrows’ time was spent in trying to overcome that reputa¬ 
tion. This reputation for mediocrity in programming was undeserved, and 
was due mostly to the fact that we did not contribute as much to the 
literature as did other organizations devoted more heavily to research. The 
questions we always got from the Air Force were, “How many nationally 
known programmers do you employ?” and, “How many Ph.D.’s do you 
have in the programming business?” 

Burrows was very competent, but was overloaded by the charge 
that was given him. The undeserved reputation for mediocrity dogged 
him, and he was not able to find a satisfactory balance that would alleviate 
the pressure. Burrows eventually went to work for the Air Force, as 
the assistant to Major General J.T. Robbins at Air Force Headquarters. 
Robbins had the Air Force responsibility for managing software and 
computer purchases, and Burrows was finally on the other side of the 
questions. 
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CHAPTER 25 


MEETING THE NEED FOR PROGRAMMERS 


One of the biggest problems I faced when I came to work with 
Wieser was finding trained programmers. The people at Lincoln who 
knew how to do the programming had been working almost full-time on 
the Cape Cod System through 1954, and although they knew they were 
going to pick up the responsibility for the SAGE programming, they did 
not know exactly what the programming demands would be. First, the 
SAGE program had to be developed as a master program for many sites; 
second, it involved the FSQ-7 computer, which was quite different from 
the Whirlwind computer; and third, it involved the training of new pro¬ 
grammers for the FSQ-7 so Lincoln could eventually phase out of the 
programming aspect of the system. We projected that we needed over 200 
new programmers and presented this problem to the ADES Project Office. 

By the time I joined Wieser in Group 61, the programming 
requirements were emerging from the organizations involved in the SAGE 
job. We concluded that in order to have enough trained programmers to 
carry on the job, it would be necessary for us to set up a training course, 
and IBM was asked to do this. 

Division 6 refined the estimates that had been made earlier on the 
number of programmers that would be required. Lincoln would need 
programmers to do the first version of the master program and to install it 
at the first three sites as well as to develop the first version of the combat 
center program. RAND was committed to preparing programs for subse¬ 
quent sites, including adapting, maintaining and revising the master pro¬ 
gram during the evolution of the SAGE system and the integration of new 
weapons and sensors. In addition to that, RAND needed programmers to 
supplement its STP operation, and had committed itself to building up a 
staff of 200 programmers for the STP by 1957. Bell and Western Electric 
needed programmers for both the acceptance test and the evaluation. IBM 
needed programmers to do internal diagnostic programming and to instruct 
novices in the training course they were offering. The initial requirements 
for programmers were based on estimates for producing the operational 
program. Since the utility programs were to be drawn from those programs 
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used in the preparation of the master program, additional people were not 
expected to be needed for this task. 

Over the course of a year, IBM trained over 200 people at their 
XD-2 facility in Kingston, giving each person two months of training. The 
estimate that was used at the beginning of the course called for 55 Lincoln 
people, 58 RAND people, 16 ADC people, 24 Bell people, 29 Western 
Electric people, and 31 IBM people to be trained. This course was remark¬ 
ably successful. Before the formal course was finished, over 500 program¬ 
mers had been trained. 

Although we naively thought that only engineers could become 
expert programmers, we found them in short supply, and were forced to 
look for other professionals who could perform the task. Mathematicians 
and others from disciplines in science, as well as some from very unlikely 
(to us) disciplines, such as music and psychology, were forced, like square 
pegs into round holes, to fit. To our surprise, it was soon evident that this 
broader approach created almost the same number of competent program¬ 
mers as we might have reached using only engineers. 

In order to understand the programmer situation, one should 
know that an “experienced” programmer was someone who at one time 
had finished the act of writing a program. More often than not, the career 
path was from some other discipline to programmer to programming 
supervisor. Many programmers only wrote one program, and then they 
were given the job of overseeing the next new bunch of recruits. Lincoln 
sent recruiters to college campuses all over the country to dig up candidate 
programmers. 

One University of Chicago student, Richard C. Jeffrey, was 
attracted by Lincoln’s ad in the Chicago Tribune that called for logical 
designers. Dick decided to investigate the opportunity, and tells of stand¬ 
ing in line for an interview. Dick was a philosophy major whose specialty 
was logic. When it finally came time for the interview, he confronted the 
recruiter with what he thought was his obvious fit to Lincoln’s needs. In 
spite of the fact that he and the recruiter could not come to terms on a 
definition for “logical designer,” the recruiter’s last words were, “I don’t 
know what to do, but we haven’t got any logicians and maybe we ought to 
hire some.” Jeffrey ended up being hired and was assigned to a systems 
analysis group, which contained a variety of people whose functions were 
never clear, or who never found a niche in the SAGE project. It was ano¬ 
ther coincidence that Jeffrey had come from American Television and had 
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taught the same courses I had taught there. I remembered him vividly, 
because I had picked up one of his classes in differential calculus, a class 
that was happy with Jeffrey as an instructor and that saw me as a poor 
substitute. Jeffrey had a habit of walking with his head down and not being 
aware of the people around him. I claimed that he recognized people by the 
types of shoes they wore. Years later, he would earn his doctorate in 
philosophy, and became a professor at Princeton University. 

Others in the systems analysis group included H.R.J. Grosch, 
who had had some experience at IBM, and Irving S. Reed, a theoretical 
mathematician who came from CRL where he had worked on the beam 
splitter for the AN/FST-2. Grosch was also a logical designer who 
couldn’t apply his Boolean algebra to the SAGE problem. He proposed a 
computer that used ternary arithmetic, which theoretically would have 
resulted in a reduction of the number of components in the machine, but he 
neglected the engineering problem of adding another stable state to each 
register. Reed was unable to find a place for himself in the straightforward 
system engineering job. Eventually, most of the members of this group 
were placed in other jobs around Lincoln, although Grosch left and Reed 
took a job with a consulting firm on the West Coast. Jeffrey was assigned 
to the Systems Office. 
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CHAPTER 26 


SCHEDULING AND OTHER PROBLEMS 


We had all grossly underestimated the overall programming job 
for SAGE. During the early part of 1954, it had become clear that the 
programming job would be much larger and much more expensive than we 
had predicted. The operational program would be over 100,000 instruc¬ 
tions and the utility and instrumentation programs would be almost as 
large. In 1955, for example, the Lincoln Utility System contained about 
40,000 instructions, and the cost of programming at that time was esti¬ 
mated by Herb Benington to be about $55 an instruction word. 

In 1956 enough was known about the computer programming job 
requirements so that we could state with certainty that we were too 
ambitious with respect to the capacity requirements for tracking and 
interception that we had originally set, and that it would take considerably 
more time to train the programmers and create the program than we had 
anticipated. This was a very delicate matter because the whole SAGE 
schedule was keyed to the availability not only of the FSQ-7 machines, but 
also of the operational programming. Wes Melahn and I and the program¬ 
ming team made our best estimate of when the first operational computer 
program could be delivered; we concluded, reluctantly, that it would take 
approximately another year beyond the schedule to complete the program. 

It was my duty to report this news to the ADES Program Office. 
The news was viewed with both alarm and relief by everyone there — 
alarm because of the slippage, and relief because other slips which had not 
been reported in other parts of the system could be masked by the major 
slip in the program. It was partly this slippage that caused tension to 
escalate between Division 2 and Division 6. This tension over the manage¬ 
ment of the program was to increase as time went on. 

An example of a subsystem that was also behind schedule was 
Division 2’s FST-2 radar data processor. The processor that was used in 
the experimental transmitting of video signals from the radar to the central 
computer existed in “breadboard” form, and had to be turned into a 
production model and installed in the field on a crash basis in order to catch 
up to the rest of the system. The Burroughs Corporation did a magnificent 
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job in accomplishing this in a short time (18 months) under the guidance of 
Jack Harrington’s group. 

Periodically, the New York Project Office would report to Gen¬ 
eral Earle E. Partridge, ADC commander and later to become the first 
NORAD commander, on the progress of the SAGE system. These presen¬ 
tations were usually given by Colonel Scott, who was a thorough and 
competent reporter. General Partridge had previously been head of ARDC 
and had come to know the Lincoln organization and George Valley in 
particular. Partridge and Valley seemed to have a rapport, and Partridge 
had confidence in what George was supporting. I remember attending one 
of the progress report meetings in the NORAD command post in Colorado 
Springs, with Partridge at the head table, his staff surrounding him. 
Lincoln and other groups occupied a bleacher-like seating arrangement. 
Colonel Scott went through his report which, at this time, included the bad 
news about the schedule slip. Afterwards, I talked with one of the colonels 
who was responsible for coordinating the NORAD command’s participa¬ 
tion. He told me that Valley had already made a separate report to Partridge 
and that Partridge accepted Valley’s judgment, which corresponded to that 
expressed by Scott. This private meeting was typical of Valley’s inner- 
circle maneuvering. 

On the way home from Colorado Springs, Bob Everett, Norm 
Taylor, George Valley, myself, and others were grounded in Chicago by a 
snowstorm. We were put up at a hotel in Chicago for the evening. Since I 
had spent the better part of 10 years in Chicago, I was the man the group 
looked to for planning a recreational evening. I was the junior member of 
the group and took them to the Rathskeller of the Old Heidelberg, where 
you can drink beer and sing German songs. It became very clear that I had 
mistaken the sense of the group. In retrospect, I would have done better to 
have taken them to Calumet City — Chicago’s Times Square. It turned out 
that both they and I were hung up by protocol: the junior member of the 
group should not make too much of liking “show bars,” and imply that his 
superiors would want that, and his superiors were unwilling to come out 
and say what they wanted, as it might be a bad example for the kids. 

In order to expedite the schedule, Group 61 devised a way of 
controlling the program through the use of a hierarchy of specifications — 
from the Lincoln/ADC Red Book (Operational Plan) to the actual coding. 
At the highest level was the Operational Plan, prepared by Lincoln senior 
staff and Colonel Tom Halley’s contingent from ADC, which guided the 
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development of the operational specifications. Dave Israel and Charlie 
Zraket, in conjunction with Colonel J.D. Lee’s 4620th Air Defense Wing, 
had responsibility for the development of the operational specifications 
which described the transfer functions that would be performed in terms of 
inputs and outputs. 

Israel and Zraket were both outstanding men. Dave Israel had 
been an undergraduate at MIT as well as a graduate student. Israel never 
got over his liking for programming in machine code, and he swore by it 
throughout the period of the Cape Cod System and well into the work he 
did on the SAGE system. I had dealt with Israel on the instruction set for 
Whirlwind II/FSQ-7 as well as on the design for the central processing unit 
as a whole. He was a very bright, self-initiating, competitive engineer, 
who was famous for his aptitude test for programmers. He devised this test 
himself, and gave it to all new employees being considered for work as 
programmers. Since there weren’t many programmers in the country and 
because there was no standardization of order codes or similarities in the 
usage of the computer, each development program for digital computers 
emphasized a slightly different twist. As we mentioned before, Whirlwind 
emphasized processing speed and reliability. 

My first encounter with Dave in a social setting was in a restau¬ 
rant in Poughkeepsie. We had both gone to Poughkeepsie to participate in 
the selection of the order code. I looked at the menu and decided I wanted a 
drink before dinner. I selected a drink that I had never had before called 
applejack, which is alcohol made out of apples. This gave Dave the 
impression that I was extremely sophisticated, well beyond the fact of the 
matter. He always remembered that occasion. 

Charlie Zraket had graduated from Northeastern, and joined the 
Digital Computer Laboratory the same year I did. He did his master’s 
thesis at MIT on the buffer drum memory. He worked on the time-division 
data link, created one of the first weapons control programs, and partici¬ 
pated in the Cape Cod experiments before he was given the responsibility 
for a major part of the SAGE operational specifications. Charlie was an 
extremely well-organized man, orderly in his thought and in his personal 
life. He was characterized by Howard Kirshner, a Division 6 engineer, as 
being so neat that he drove his car at 50 mph so that the two halves of the 
speedometer would be of equal size. Zraket was smart and productive and 
had a low frustration flash point. He had a habit of blowing his top, and his 
arguments would become hyperbolic. Once the storm was over, Charlie 
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would forget it and continue to operate serenely until the next time the 
pressure developed. In spite of these characteristics, he was very reliable 
and I liked to have him on my projects because I knew they would be done 
right — and a little destruction of the furniture was a small price to pay. 

The group under Charlie Zraket prepared the operational specifi¬ 
cations and these were cleared with the 4620th and given to Benington and 
Amow who had the responsibility for the programming specs. The pro¬ 
gramming specs outlined, in flow chart form, some major subfunctions 
that would have to be performed in order to satisfy the operational 
specifications. 

Shortly after we announced the slip in the program, the specifica¬ 
tions were showing up the capacity that each program required for its 
execution. The basic cycle for the master program was approximately 17 
seconds, based on the time that it took for one rotation of a long-range 
radar. An analysis of the time it would take for running each of the 
procedures on each piece of data, as well as for performing all of the more 
general functions, showed that we would not be able to meet the intended 
track capacity of the system. This called for a general paring back of the 
program, and a rather drastic cut was made in some of the functions. Other 
remedies included rewriting certain sections of the program, as well as 
dropping some functions entirely. At any rate, the program was not only 
late but required a significant overhaul. 

About that time, George Valley set up a series of seminars in the 
Lincoln cafeteria to exchange information on various aspects of research 
that went into air defense. I was asked to prepare one of these seminar 
sections on the SAGE programming business. I was hesitant to do it since 
there were programmers around who had considerably more experience 
than I did, so I spent the better part of a week reviewing what all the people 
who worked for me were doing and drafted a speech which was partly 
tongue-in-cheek, partly tutorial, and partly to introduce the Division 6 
people to the rest of Lincoln. I called it “The Romance of Programming,” 
and it seemed to have been the best thing I’ve ever done. More people 
remember me for that speech than for more significant contributions I 
made to the program. 

Valley had responsibility for Division 2 as well as his responsi¬ 
bilities as associate director of the laboratory. Forrester remained in charge 
of Division 6, but tension was growing between the two divisions. When 
the slippage occurred, Valley took the opportunity to make management 
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changes — ostensibly to improve the efficiency and balance of the organi¬ 
zation. Wieser, one of the key people in Forrester’s division, was trans¬ 
ferred along with the responsibility for the Cape Cod System and promoted 
to become associate head of Division 2. Valley resigned his position as 
head of Division 2, concentrating on his responsibilities as associate 
director, and promoted Carl F. J. Overhage to head Division 2, with Jack 
Harrington as second (to Wieser) associate head. With this reorganization, 
Valley attempted to circumvent the competition between the divisions, but 
actually only escalated it, and, in 1956, Forrester resigned to accept a 
position as full professor at the MIT’s Alfred P. Sloane School of Manage¬ 
ment and to work on the patent for his invention of the random access core 
memory. Bob Everett succeeded Forrester as head of Division 6. I 
remained in Division 6 as assistant division head, retaining the responsibil¬ 
ity for the SAGE operational computer program. 

The Valley reorganization, which had led to all of the personnel 
changes, did not, as had been intended, close the rift between Divisions 2 
and 6. Part of the purpose of the reorganization had been to ensure that the 
technical results turned up by the Cape Cod System would influence the 
design of the various parts of the SAGE system. Wieser, and a number of 
other management people, felt that the Cape Cod System results were 
being deliberately ignored, or at least subordinated to the problems of 
hardware and software production and scheduling. Just prior to Valley’s 
leaving, Overhage called a meeting of Division 2 and Division 6 supervi¬ 
sors to work out a modus operandi and to clarify the issues that were 
supposedly preventing feedback from the Cape Cod System to the SAGE 
system. The meeting was surprisingly tense, and the attitudes of the 
participants bordered on hostility. Overhage, who had called the meeting, 
apparently believed that simply talking over the problem would lead to an 
operational solution. The meeting began with a summary by Bob Wieser 
of the presumed lessons that were learned from the Cape Cod System. This 
speech, along with others by Division 2 people, simply reinforced the rift. 
The Division 6 people who were caught up in the SAGE design and 
production believed that they had all they needed from the Cape Cod 
System to go ahead and freeze the specifications of the hardware elements 
and most of the software. Everett, in his characteristic way, took the 
position that the design was essentially set and it would require significant 
argument and proof to change it, and he stated that he was willing to 
change anything for which Division 2 could make a substantial case. This, 
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of course, put the burden on Division 2 to demonstrate the consequences of 
small changes on performance of the system. It called for more effort than 
Division 2 had manpower, and presumed that the SAGE design had 
already taken into account the lessons learned from Cape Cod. The judg¬ 
ment of whether or not it did was not delegated to any group or person, so 
Division 6 won by default. 

All of this non-productive activity served to reinforce Over- 
hage’s opinion of Division 6 as being obstinate and rigid. I could feel the 
change in Overhage’s mood during the course of the meeting as it turned 
from a benevolent hopefulness to a resigned discouragement. I think that it 
contributed to his willingness to encourage Division 6 to split from Lin¬ 
coln, and, at the same time, made him unwilling to rely as much as he 
should have later on our inputs to the process of formulating the structure 
of The MITRE Corporation. This would be the genesis of the sentiment 
that the original MITRE technical groups were part of a “Good Old Boy” 
network. The original MITRE team was referred to as the “Lincoln 
clique.” This sentiment would continue to be used as an argument for get¬ 
ting new blood into the organization, until Bob Everett eventually became 
president of MITRE, and the situation was put into better perspective. 

Shortly before Forrester transferred back to the Institute and took 
up duties as a professor, I accompanied him to an air power demonstration 
at Eglin Air Force Base in Florida. At that time the Air Force annually put 
on a show of the capabilities of aircraft in the Air Force. It included 
bombing, strafing, reconnaissance flying, photo taking, and the whole 
ensemble of aircraft functions. On the way back from the demonstration, 
we stopped in New Orleans. As I had never been there before, I was glad 
that we managed to see many of the cultural sites such as the above-ground 
burial cemeteries, and the French architecture. In the evening, most of the 
people disappeared down Bourbon Street. I wanted to go also, but Jay 
wasn’t having any of it and I felt obligated to keep him company, so I 
missed one of the most renowned features of one of our most important 
cities! 
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CHAPTER 27 


A PROMOTION AND THE STEERING COMMITTEE 


After Forrester left Lincoln Laboratory to go back to MIT, Bob 
Everett was named head of Division 6. He chose Norm Taylor to be his 
associate head. Almost immediately, however, Taylor was invited to 
participate in a study on defense under H. Rowan Gaither, then head of the 
Ford Foundation, and he went to Washington. Shortly after his return from 
Washington, Taylor left Lincoln to become president of Scientific Engi¬ 
neering, Inc. He was later to go on to become one of the vice presidents of 
the Itek Corporation. When he left Lincoln Laboratory, I was made 
associate division head under Everett, and a member of the Lincoln 
Steering Committee. 

In the five or so years that the laboratory had been in existence, 
the directorship had turned over three times. Marshall Holloway’s 
attempts to smooth relations with General Power and the Air Force had not 
gone well; for this and other reasons, Holloway left the Laboratory. 
George Valley, too, left Lincoln. I remember going to a cocktail party at 
Admiral Cochrane’s house given in Valley’s honor, to which the division 
heads and associate heads were invited. Everyone there seemed to be 
unaware of the reason for the party, and George could just as well have 
been one of the guests. I remember thinking that it was just as well that it 
was handled that way, without speeches or sentimentality. Valley returned 
to MIT as a full professor (perhaps as part of the settlement) and took the 
job of chief scientist with the Air Force shortly after that. 

Carl Overhage was promoted from his position as head of Divi¬ 
sion 2 to become Lincoln Laboratory’s fourth director. He was in charge 
when I became associate division head. Carl was a statesmanlike, genteel 
diplomat, who more or less expected that a gentle suggestion would be 
enough to persuade his subordinates to do the right thing. But under his 
old-world gentility was a hint of an iron will — he even had a slight foreign 
accent. He was a good example of successful typecasting, complete with a 
magnificent pair of arched, bushy eyebrows. 

By the time I joined the Steering Committee, many of its ori¬ 
ginal members were gone. Among those who had not left was Henry 
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Fitzpatrick, who was Lincoln’s chief financial officer. To be a member of 
the Steering Committee, one had to be either a division head or an 
associate division head. These division heads all had their own fiefdoms 
and guarded their turf with extreme ingenuity. Although the Steering 
Committee was set up to give advice to Overhage on matters of mutual 
interest, and I think it did serve that purpose, it was nevertheless an unruly 
bunch, to say the least. One area in which there was a certain amount of 
lively discussion was in budget and finance, which was headed by Henry 
Fitzpatrick. Bob Everett, one of the original Steering Committee members 
(he had joined as associate head of Division 6), had an uncanny ability to 
upset Fitzpatrick. Everett was able to add up columns of large numbers in 
his head, something he always claimed that he never practiced doing, as it 
was just something that occurred without his even trying. His ability to do 
this added to his reputation for quickness and technical capability. As a 
financial man, Fitzpatrick often came in with long columns of numbers 
with totals in which there was often some mistake. Everett would invari¬ 
ably catch the mistake and choose the most opportune moment, one which 
would cause the greatest effect, to point out the mistake. This would 
usually put Fitzpatrick off his stride. It seemed to contribute to his doing 
the same thing over again at the next meeting. 

There was very little discussion of the SAGE problem at these 
meetings by the time I became a member; the Committee was much more 
concerned with research and development. Ben Lax, associate head of 
Division 3, was interested in creating a magnet laboratory where magnet¬ 
ism could be studied. His proposal envisioned a magnet that would take 
half the water in the Charles River to cool. I found it an interesting group, 
and became close friends with Joseph A. Vitale, who headed Division 7 
which ran the shops and other services for the laboratory. Joe Vitale and I 
spent a lot of time in what we thought was humorous banter, but, as time 
went on, it became clear to us that Overhage did not appreciate this, and 
our behavior contributed to some of the tension surrounding my support of 
Overhage’s planning with the Air Force as it tried to take over the manage¬ 
ment of the SAGE system. In retrospect, I think if I had been more 
sensitive to Overhage’s feelings, the difficulty Everett and I would experi¬ 
ence during the time that Overhage and General James McCormack, Jr. 
were setting the stage for The MITRE Corporation might have been 
moderated. I believe that Bob and I could have had more influence on the 
principles established. 
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As Bob Everett’s associate, I quickly developed a way of work¬ 
ing with him which utilized both of our strengths. Bob tended to act as a 
filter on all the internal actions of Division 6, as well as on the work 
program and products. He was a decision procrastinator, leaving his 
options open until the last possible minute. On the other hand, I devoted 
myself to putting pressure on those who were assigned different tasks and 
seeing that there were products that could be filtered by Bob. I was an 
initiator who proposed actions and gave out the orders. I saw to it that the 
decisions that were required were made. This often meant that I formu¬ 
lated instructions for Bob to approve, and he in turn released his potential 
action items to me for action or distribution. Beyond this division of labor, 
we acted as each other’s alter egos on the entire Division 6 program. I 
generally took the role of counterpart to the Air Force program officers, 
and Bob tended to take the role of scientist, through his association with 
the Scientific Advisory Board and other similar committees. It seemed that 
it was a good match because we became quite proficient at this way of 
working. 
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CHAPTER 28 


SAGE BECOMES OPERATIONAL 


■he master program was created at Lincoln and tested on the 
XD-1 under the guidance of Jack Amow and Herb Benington. As soon as 
it cycled — stepped through the air defense process without hanging up — 
we began to implement its installation at the first three SAGE direction 
center sites. Ben Morriss and his associate, Kenneth E. McVicar, were 
given the responsibility for installing these programs at the sites. 

I had known Ken McVicar since I was an MIT research assistant 
and lived in Westgate West. At that time, Ken was working at the Digital 
Computer Laboratory, but had decided that he wanted to go to law school. 
He spent some time at Harvard Law School, decided he didn’t want to 
pursue law, and came back to the Digital Computer Laboratory. As Ben 
Morriss’ associate group leader when the master computer program was 
installed at the first three SAGE sites, he bought a new Chrysler to 
circulate among McGuire, Stewart, Syracuse, Poughkeepsie and Kings¬ 
ton, seeing that everything was being handled properly. Since the facilities 
at XD-1 were limited to a simplex computer, all duplex features had to be 
tested out on a duplex machine. Thus, we requested of IBM the use of the 
FSQ-7 duplex machines which were in the test cells at Kingston during 
construction of the field machines. 

Ken was a collector of clocks and other things. He never lost the 
natural curiosity of his childhood. He tells a story of being out with his son 
who said to him, “Daddy, I’m glad you didn’t grow up, like other 
daddies.” In addition to clocks, he collected ship models. He built radio- 
controlled airplanes, and sailed. He was also an amateur magician. I 
remember a party we had at our house when Ken was sitting with the 
Commander of the Electronic Systems Division and one of our other 
friends. To show a magic trick, he asked for the use of a handkerchief. It 
was offered by my other friend. The trick involved stuffing the handker¬ 
chief through his fist, lighting the protruding center of the handkerchief 
with a match, pulling it back through his fist, and voila! The hole that was 
burned disappeared! Only this time, it didn’t. Ken was faced with having 
to give back this burned silk handkerchief to its owner. 
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As a member of the SAGE team, Ken was aggressive but never 
pushy. At raise time, he would always object to the amount of his raise on 
the grounds that he didn’t deserve it. Similarly, on promotions, he was 
quick to point out that others deserved a promotion as much as he. His 
characteristically gracious and fair-minded ways, as well as his proven 
reliability, stood him in good stead and he continued to rise within the 
organization at Lincoln, and later within MITRE. 

The differences in physical characteristics of each site required 
that there be a mechanism for adapting the program at each site to the 
system. The adaptation process allowed particular features of a sector to be 
added to the program and tested for errors. The Air Force was responsible 
for providing Lincoln with the adaptation parameters — which included 
information such as location of radars, airfields, ground-to-air radio, and 
geographical features of importance. A team of Lincoln people supple¬ 
mented by RAND staff took these modified master programs to the sites, 
where their first job was to make the program cycle through all its pro¬ 
cesses without hanging up. The first program installed was at McGuire Air 
Force Base in New Jersey, and it was stepped through all its advertised 
capabilities by A1 Roberts, one of Ken Me Vicar’s men who headed an 
installation team. A1 was an intense, emotional, and capable engineer. 
When excited, he developed a tremor which added to the effect. A1 
received his master’s degree from MIT in 1953. He had been a research 
assistant, worked on the storage tube memory for Whirlwind I, and then 
worked on the Cape Cod System. 

Errors were caught and corrected by an on-site team. We had not 
predicted the volume of these errors, and in the process of the installation, 
we got a better fix on the need for maintenance programmers to remain at 
the site to maintain the master program. Me Vicar, working for Ben 
Morriss, was given the responsibility for seeing that these master pro¬ 
grams, adapted to the particular site, worked as expected. 

The computer and the computer program first became opera¬ 
tional at McGuire in the summer of 1958. A party was set up to celebrate. 
It was a disorganized affair, attended by the press and by people who had 
played a role in the development of the SAGE system. My memory of it is 
not very clear, but I do remember a story told by Carl Overhage, who was 
the master of ceremonies. It was about Texas and Texans, and how 
everything in Texas is big — big men, big hats, and so on. An Easterner 
went into a bar, and the bar was shoulder-high to an ordinary-sized person, 
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but just right for a Texan. The bar stretched for hundreds of yards and the 
beer was served in gallon-sized jugs. After drinking a beer, the Easterner 
staggered to the end of the bar and towards the rest room, but he opened the 
wrong door and fell into a swimming pool. While he was struggling to stay 
afloat, two Texans came through the door. Horrified, the Easterner yelled, 
“No! Hold on a minute! Don’t flush it!” 

Lincoln was also responsible for building the combat center 
programs. The combat center consisted primarily of a large-scale display 
that enabled an air division commander to manage and monitor air defense 
operations being controlled at the sector direction centers. It received its 
surveillance and weapons control information from the direction centers 
within the air division. The combat center, via data link, also kept an 
inventory of the status of forces available to its air division, and was 
responsible for allocating interceptor aircraft supporting the air division 
through the direction centers. 

A team under Walter S. Attridge, one of the Lincoln men, was 
assigned to Hancock Field, Syracuse, New York, to create the combat 
center master program and install it at the 26th Air Division’s new SAGE 
facility. Attridge had been one of the original programmers for the early 
Whirlwind experiments and the Cape Cod System. His team was com¬ 
posed primarily of RAND and SDC employees along with a few Lincoln 
employees. The combat center program was much less complicated than 
were the direction center programs at the sites, and it turned out that this 
team was able to produce the program faster than the schedule called for 
and at less cost than was estimated. It was probably a first (and last?) in that 
regard. The first combat center was declared operational in the fall of 
1958. 

The first SAGE sector was assigned to Brigadier General Arthur 
C. “Sailor” Agan when it went operational. Shortly after that, a major 
design flaw was discovered: the tracking program was creating more than 
one track per aircraft. It was concluded that it was a “registration” prob¬ 
lem. One of the features of the system was the overlapping radar coverage, 
and the registration problem might have been caused by having an error in 
the location of one of the radars. Since at least three radars could see the 
space at the same time, an airplane flying through the space would be 
reported by three different radars. These returns would not be synchro¬ 
nous, but were supposed to lie on a track corresponding to the flight path. 
Agan made a fuss about it, and we dispatched a team to analyze and correct 
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the problem. That team was headed by John H. Monahan, who was 
assisted by two people from our South Tmro site. Jack Monahan had 
joined Lincoln after graduating from Boston College, where he had earned 
a master’s degree in mathematics. Initially, he spent most of his working 
time on the Experimental SAGE Sector (ESS). Jack played a cmcial role in 
the design of the SAGE surveillance system. He applied stereographic 
projection to compensate for the earth’s curvature and solved many of the 
other problems associated with creating a common grid for locating all 
points in the sector’s air space. He contributed to the plan that would lead 
to the BUIC (Back-up Interceptor Control) system, and became its project 
leader. Jack was a level-headed, laid-back, no-nonsense manager who 
could be counted upon to solve most of the software and hardware prob¬ 
lems that came his way. He had a way of treating his subordinates fairly, 
which added to his general competence and created a desirable environ¬ 
ment for the staff who reported to him. 

In trying to track down the registration problem, Jack and I 
chartered an airplane from Provincetown/Boston Airlines, which flew a 
plane manufactured by Cessna that was then known as the “Bamboo 
Bomber,” because of its wood and fabric construction. The Air Force 
would not let us land at McGuire, and we were waved off. We were forced 
to land on a dirt strip in Red Bank, New Jersey, and take a cab to McGuire. 

When we arrived at the McGuire direction center, we were 
shown the symptoms of the problem; namely, each airplane generated two 
or more tracks. It was discovered that the National Geodetic Survey data, 
used for radar position information, had been incorrect. The Air Force had 
to get the correct position data in order to modify the locations held by the 
computer. This was done, but the problem of multiple tracks still 
remained. 

Each site had both beacon and radar antennas, and attention was 
then turned to the alignment of the beacon antenna with the radar antenna. 
The beacon was used for Identification, Friend or Foe (IFF) and to 
enhance the radar returns from the interceptors, which were smaller than 
the bombers. The beacon antenna was attached to the top of the radar 
antenna and every beacon radar was slightly off-center with respect to the 
radar antenna on which it sat. There was a separation between the angles 
reported by the two antennas. The result of this was that the beacon- 
reported position would be off from the radar-reported position enough so 
that the tracking program presented two tracks to the surveillance system. 
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The designers of the program had anticipated this problem, and solved it 
by adding a correction to the angle reported. In fact, the beacon and radar 
antennas were lined up mathematically in the computer. The correction 
parameters were right but carried the wrong sign: plus instead of minus! 
Instead of subtracting the difference, the program doubled the correction 
and increased the problem. After the error was found and rectified, the 
“registration” problem went away. 

Although we had anticipated the majority of the problems we 
would face in the field, there were nonetheless unpredicted problems that 
required a knowledge of the details of subsystem designs. Those people 
who had had a hand in the designs were pressed into service whenever the 
field system showed the need. 
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CHAPTER 29 


SAGE SYSTEMS TESTING 


As the SAGE design progressed from the component to the 
system level, Lincoln’s testing philosophy evolved along with it. This 
philosophy was to be characterized by the use of simulations to determine 
the operating characteristics and reliability of a specific subsystem or 
component within the larger system. As a component reached completion, 
a breadboard or prototype was built which would then be subjected to as 
close an approximation of the external environment as could be achieved 
with available testware. If crucial testware was not commercially avail¬ 
able, it was built in the laboratory. In this way, Lincoln was assured of 
thoroughly tested, predictable parts that had been tested as they would 
work in the whole. 

In the early stages of development of Whirlwind I, for example, 
the individual electronic circuits were built and tested. Then, larger aggre¬ 
gates of components, such as the five-digit multiplier and the memory test 
computer, were built and tested to determine if these principal components 
of the system worked as the designers had expected them to work. This 
procedure progressed up the line as larger and larger aggregates were built: 
the high-speed memory was added, then the drums, then the input/output 
equipment, and so on. At each step, the appropriate tests were made of the 
added parts working as part of the whole system. 

The same philosophy was followed when the project reached the 
Cape Cod System stage, when the peripherals were added to the computer. 
Several radars were added along with phone line connections and radar 
connections, so that the system could be tested in terms of overlap cover¬ 
age. Similarly, the air surveillance elements were then tested together to 
provide an air surveillance picture. With both the tracking and surveillance 
portions of the system now operating, the weapons direction system could 
be assembled. 

An important principle that engineers tried to apply to this kind 
of additive testing was to look directly at the function being tested, and do 
no more than would assure that first, the system would work, and second, 
that it would come somewhere close to specification. One of the lessons 
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learned in this process was that the amount of overhead required for test 
and design verification was almost as extensive as the amount required for 
the system itself, at least up to the direction center level. This overhead 
(mostly testware) would contribute to a later criticism concerning the 
expense of the SAGE project. But Lincoln held to its conviction that step- 
by-step, systemic testing would avoid costly, unforseen problems later on. 

At the systems level, the process of testing was called “shake- 
down” testing, and its purpose was to demonstrate how the whole system 
worked when doing the job it was built to do. Here, the idea was not 
simply to get numbers or to verify that the system could function, but to 
provide a more comprehensive, evaluative function to the entire project. 
Testing at this level was seen as part of a process which fed back to the 
designers, who then would be expected to take advantage of shakedown 
insights to improve system performance, or to correct problems that had 
become evident under test. Shakedown testing attempted to avoid the 
isolation commonly experienced when testing is carried out by a third 
party who is tasked with acting as an honest broker. 

Overall responsibility for SAGE testing was held by Lincoln. 
Steve Dodd and Ed Rich took the lead in exploiting Lincoln’s Experimen¬ 
tal SAGE Subsector, the prototype of SAGE used to test system elements 
and to measure operational criteria. Charlie Grandy was their associate. 
Ed Rich was an excruciatingly thorough, passive engineer who had a very 
good reputation from his work on Whirlwind, where he was in charge of a 
sort of “autopsy” group that analyzed every failure of vacuum tube or 
other component that went into Whirlwind. This activity was carried out 
by Ed with the support of a number of Whirlwind people, so that the choice 
of components could be based on actual experience. It was largely due to 
this activity that special vacuum tubes were designed by the manufactur¬ 
ers. And where Ed Rich developed the reputation for being slow, he was 
very careful and thorough in his diagnoses of component failure, and his 
work was responsible for informed judgments about the components. 
Charlie Grandy, on the other hand, was articulate, stubborn, confident and 
quick. Rich and Grandy carried out the shakedown process associated with 
functional capabilities, surveillance, identification, tracking and weapons 
control. 

In addition to the shakedown tests, which were performed by 
Lincoln and IBM, acceptance tests were run at each of the SAGE direction 
centers as part of the acceptance process of the operational sites. Lincoln 
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was contractually obligated to specify the acceptance test, but in actuality, 
Bell Laboratories provided the manpower for this task. In many cases, Bell 
Labs’ experienced staff proposed the test specifications, which were then 
signed off by Lincoln. Bell Labs also fulfilled their contractual responsi¬ 
bility of translating the acceptance test specifications into workable test 
methods, to be carried out in the field by Western Electric at the various 
SAGE sites. 

The Bell-Western team was represented at Lincoln by Mike 
Burger, who had an office just outside the offices that Bob Everett and I 
worked in. He was a tall, affable, pear-shaped man who was given to long 
speeches about how things were done at Bell Labs. His most visible 
preoccupation was with his relative rank among the contractors and Air 
Force organizations that were participating in the SAGE job. I remember 
going to see him to talk about the test specs. His first reaction was to decide 
whether I was at an appropriate level in the Lincoln organization to be 
speaking to him. He had the organizational hierarchies of all the participat¬ 
ing contractors drawn out on a paper and his level, he felt, corresponded to 
either Jay Forrester or to Marshall Holloway, the director of Lincoln 
Laboratory. In spite of this, we were able to work with him. 

Within the Air Force, the testing area was the responsibility of 
the New York Project Office, but at Lincoln, the testing was monitored by 
Colonel William C. “Scottie” McLaughlin from ADSID. Scottie was a 
nervous, excitable gadfly, and he was continually proposing new tests that 
ought to be run. People liked him at first when he was operating as part of 
ADSID, but in time it seemed that his ambitions to manage the processes 
overcame his assignment to monitor what was going on. He set about 
trying to build a functional organization that would make testing a separate 
activity, rather than one of several steps in the development process that 
provided feedback to the design. His status in the Air Force was never 
quite clear to us; in fact, our most serious problem with Scottie was his 
lack of status. This lack became evident when he was not invited to a 
Lincoln Christmas party because he didn’t rank high enough in the organi¬ 
zation to be invited — the list of Air Force attendees had been made out by 
his superiors in the Air Force. We heard through various branches of the 
grapevine about the “status problem” and we felt badly for Scottie and had 
him invited. But his presence caused such an atmosphere of tension among 
the higher-ranking Air Force people at the party that the Air Force decided 
not to become involved in future Lincoln Christmas parties. Besides, the 
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Air Force was starting to think that Air Force/Lincoln parties might 
represent a conflict of interest. 

Acceptance testing presented designers with a thorny problem, 
as it was difficult to project from a subsystem’s test results its performance 
within the system. But in general, the range of performance expected of a 
particular machine or subsystem being accepted was determined by com¬ 
paring it to the performance on the Experimental SAGE Subsector, when¬ 
ever that was practical. 

The Bell-Western team held the responsibility for evaluation, the 
last formal step in SAGE testing. Here again, it was hard to be definitive 
about what to expect in evaluation testing, as no acceptable definition of 
the system’s value could be determined from contrived scenarios. The best 
that could be done was to demonstrate how well the system would perform 
each of its basic functions, in comparison to what the Experimental SAGE 
Subsector had demonstrated was possible during the shakedown and other 
testing. 
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CHAPTER 30 


DIVISION 4 


Within Lincoln Laboratory, Divisions 2 and 6 were dedicated 
to the SAGE job. The people in those divisions had come primarily from 
MIT’s Digital Computer Laboratory and the Air Force Cambridge 
Research Center. Two other Lincoln divisions were peripherally involved 
in SAGE: Division 3, Communications and Components, and Division 4, 
Radar Systems and Components. Many Division 3 staff had worked under 
A1 Hill at the Research Laboratory of Electronics, and had come with him 
when he joined Lincoln. This division concentrated on long-distance 
communications, and was working on troposcatter techniques. Division 3 
fed information obtained from the Distant Early Warning (DEW) Line 
System into the SAGE communications network. Division 4 was dedi¬ 
cated to radar research, and covered ground radar as well as airborne 
surveillance radars. Although technically the radars were not a part of 
SAGE, the interfaces between the radars and SAGE presented serious 
integration problems. This was the area where Division 4 operated with 


us. 

Like Division 3, Division 4 drew heavily on people from RLE. 
Division 4 was headed by Louis Smullin, a professor on loan from the 
Electrical Engineering department at MIT. Smullin was concentrating on a 
project called “Porcupine,” a competitor for what was to become the 
Raytheon Hawk ground-to-air missile system. Porcupine depended on a 
large number of short-range radars. After the Army decided to concentrate 
on Hawk, Smullen returned to the MIT campus, turning over the division 
head job to Jerome Freedman. Jerry was a graduate of City College of New 
York in electrical engineering, and the Polytechnic Institute of Brooklyn. 
During World War II, he was in the Signal Corps and was stationed in the 
Pacific, where he was responsible for installing long-range, low-fre¬ 
quency search radars built by Westinghouse. Toward the end of the war, 
the new CPS-1, CPS-6 and MEW microwave radars were sent out, but 
they had a problem with backscatter clutter off the water. 

In 1952 while at Lincoln, Freedman was involved in the “Sum¬ 
mer Study Group — 1952,” the project headed by Jerrold Zacharias of 
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MIT, investigating early warning for air defense of North America. A 
group was formed, which became Lincoln Group 45, to do work on 
airborne early warning (AEW) radars. The first AEW radars operated in 
the S-band and had clutter problems. Drawing from his experience in the 
Pacific, Freedman suggested the use of UHF instead. Once the change was 
made, the clutter problems were eased considerably. This airborne radar, 
the APS-95, was improved not only by going to a lower frequency, but by 
the addition of moving target indicators (MTIs). Freedman headed this 
group, and when he was promoted to Lou Smullin’s job, Mel Herlin took 
over Group 45. Jerry was a gentle, pleasant man, and a capable and 
dedicated engineer. Because of his friendliness, and also his appearance, 
he reminded me of the home-spun comedian Sam Levinson. Jerry was to 
grow a magnificent walrus mustache that further emphasized his benevo¬ 
lent personality and enhanced his image considerably. He was invited to 
join MITRE when it was formed, but chose instead to stay with Lincoln, 
where he eventually became assistant director. 

The APS-95 radar was mounted on Lockheed Constellation 
aircraft. One of these aircraft, belonging to the Navy, was used for an 
extensive series of tests run by Lincoln. In the design of the BOM ARC 
system, it became clear that it was necessary to track low-flying airplanes 
over water and to get position data on these planes quickly. In one of the 
few meetings between Division 4 and Division 6, it was agreed that a 
direct data link ought to be included aboard the aircraft, and the data 
produced be fed directly into the SAGE network. After it was agreed that 
the idea had merit, we sold the idea to the Air Force, which, in turn, set up 
a project called the Airborne Long-Range Input (ALRI) program. William 
Canty was named project leader, and spent many years on the ALRI and 
the systems that evolved from it, including AWACS. 

One of the groups that reported to Freedman was the Ground 
Radar group, headed by Fumeo Robert Naka. Naka was one of the 
Japanese-Americans who had been interned by presidential decree at the 
beginning of World War II. Due to the efforts of the American Friends 
Service Committee (Quakers), he was able to continue his education at the 
University of Missouri and the University of Minnesota for his bachelor’s 
and master’s degrees in electrical engineering, and later, at Harvard for a 
doctorate. He was taller than the average Japanese, was a deacon of his 
church, and was generally well-liked. Although thoroughly American¬ 
ized, he retained his ancestral tradition of politeness. He would gain a 
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national reputation for his work in intelligence collection. He was to serve 
as MITRE’s chief scientist, became assistant undersecretary of the Air 
Force, and later, chief scientist of the Air Force. Eventually, he was made 
vice president at GTE Laboratories. I met Bob when we were assigned to 
the problems of integrating frequency diversity (FD) radars with SAGE. 
Bob and I became good friends, and we often engaged in a kind of repartee 
based on my trying to penetrate his oriental inscrutability, which made the 
negotiations for the radar integration activity fun as well as productive. 

Under the frequency diversity program, many radars, operating 
at various frequencies between 300 to 3000 megahertz, would be geo¬ 
graphically interspersed, making it difficult for the enemy to jam, as they 
would have to carry equipment to jam the entire FD radar spectrum. This 
program provided support for Lincoln’s development of a large experi¬ 
mental radar to cover the low end of the radar spectrum. Under Jerry 
Freedman’s direction, the radar was built and installed at Bath, Maine. Its 
antenna was placed on a circular tower 100 feet high, and the antenna 
reflector was 120 feet by 30 feet, requiring a very sturdy rotary bearing. 
The Bath radar went into operation in the summer of 1955, and was tied 
into the Experimental SAGE Subsector, for which it turned out to be an 
excellent data source. The success of the Bath radar prompted its redesign 
for use in the FD program, A prototype was built and installed on Boston 
Hill in North Andover, Massachusetts. Had the enthusiasm of the military 
for the FD program persisted, it was expected that this radar would have 
been produced for use throughout the country. 

The long-range “workhorse” radar of SAGE was the FPS-3, a 
production ground-control intercept radar built by Bendix for the Air 
Force. Bob Richardson from Bob Naka’s group was sent by Freedman to 
South Truro on Cape Cod to deal with a sea clutter problem apparent in the 
FPS-3 radar there. The “clutter” at first appeared to be random, and was 
considered to be noise, but Naka’s people found that the returns seemed to 
move out from the land by day and return to the land in the evening. After a 
short-term (one week) study of the data, the sources of the returns were 
identified as birds. The use of radar in tracking birds caught the interest of 
the Audubon Society, and Lincoln was able to contribute to the Society’s 
knowledge of the migration patterns of birds. Among other things, the 
study answered a question the Audubon Society was trying to answer: 
do migrating birds hug the coastlines or fly directly over water to reach 
their destinations? (The latter turned out to be the case.) The “clutter” 
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discovery was written up by Bob Richardson, and became the classic paper 
on the problem of radar clutter caused by birds. For many years afterward, 
Lincoln was considered to be the bird clutter expert. 
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CHAPTER 31 


THE TASK OF INTEGRATION 


As the machine and the computer program were assembled, the 
enormity of the computer system integration task stood out. The original 
SAGE design focused on the integration of existing radars and one class of 
interceptor. To be integrated now were at least three new interceptors, four 
or five different kinds of radars, “Texas Towers,” picket ships, AEW&C 
aircraft, the B-version of BOMARC, the Nike Hercules ground-to-air 
missiles, and the Talos ground-to-air missile — all to be controlled by the 
SAGE direction centers. In addition, there was cross-tell and forward-tell 
integration among the centers themselves. Originally, one of the main 
arguments for having a general-purpose computer in the air defense system 
was that computer programs could be changed much more easily than 
hardware. One of the major misconceptions of many of the SAGE design¬ 
ers was that the computer program was so flexible that integration deci¬ 
sions could be postponed, to be handled later by adapting the computer 
program. As it turned out, not only did the integration process require 
changes in the computer program, but also often involved modifications in 
the hardware in the form of new peripheral devices or modifications in the 
input/output system. Furthermore, the cost of programming, of maintain¬ 
ing the program, and of documenting the code was almost as much as that 
of building the specialized hardware. 

The integration of weapons into the SAGE system effected many 
changes in SAGE hardware and software. It was Lincoln’s responsibility 
to coordinate these changes, and that function was handled through the 
Systems Office. The original Red Book Operational Plan was modified by 
Lincoln and ADC’s Directorate of Planning into a document called the 
“Operational Employment Plan” (OEP). The OEP became the basis for 
the new specifications, which delineated the necessary changes to the 
hardware and software. These specifications were drawn up by Zraket’s 
group. The Systems Office coordinated the various changes with other 
groups, and the changes themselves were produced by ad-hoc teams made 
up of our most knowledgeable people on each added subsystem, working 
in concert with the ADC Directorate of Planning. 


130 



The largest of the integration tasks was the integration of SAGE 
with the Air Force’s BOM ARC system. BOM ARC was an unmanned 
interceptor that had a solid rocket booster which brought it to altitude, and 
ram-jet engines for cruising to the target. It also had look-down radar, 
which, when the target came within its range, took over and carried out the 
final phase of the intercept. In order to demonstrate that BOM ARC could 
work with SAGE, a two-step process was instituted. The first step was to 
demonstrate that SAGE control was adequate for BOM ARC. To do this, 
BOM ARC was placed at Cape Canaveral, connected by long distance 
phone lines to XD-2 in Poughkeepsie. The radar in the Canaveral area was 
also connected to XD-2. This single-thread demonstration went very well, 
and proved that the surveillance and control equations were adequate. 

In order to demonstrate the system aspects of the integration, a 
team was set up at the direction center in Montgomery, Alabama, under 
James J. Croke, to do more complex testing involving several intercepts 
and using all SAGE components. The test took place in Florida at the Eglin 
airbase which had a test range over water. BOMARC missiles were 
installed at Santa Rosa Island right outside of the airbase and were 
directed, based on instructions from the Montgomery direction center, to 
intercept drones which acted as targets. The tests were successful and 
proved that SAGE could automatically direct the aircraft in a multiple 
intercept situation. However, the effort and organization required to inte¬ 
grate BOMARC with SAGE led to a growing awareness that the job of 
integrating new weapons, radars and other capabilities into the system 
required central design control of all of the elements that affected the 
integration. The Lincoln team found itself immersed in the integration 
problem, under the joint direction of Colonel James Walker, ARDC, and 
Colonel Charles Minihan, ADC. 

To be truly effective in maintaining system design control, Jim 
Croke had as members of his team (in addition to Lincoln people) small 
groups of experts from IBM, Bell, Western, SDC, Boeing, Burroughs, and 
other participating contractors. Jim was a consciously unconventional 
engineering manager. He wore his hair long when flat-tops and brush cuts 
were the rage. When the hippie movement materialized in the sixties, Jim 
cut his hair short and started to dress conservatively. He was a very bright 
engineer and emotional by nature. He attributed his emotionality to his 
parentage: Jewish, German, and Irish. Jim had an extraordinary sense of 
the morale of the people who worked for him, and was very successful at 
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placing them in positions of mutual advantage. After Jim was transferred 
back to Massachusetts, the Montgomery site was taken over by Lawrence 
Holmes. The only significant change in the operation that occurred there 
was that the secretary-receptionist was discovered to be running a call 
service from the office — moonlighting, more or less. She was quickly 
terminated by Larry. 

The integration of Nike, the Army’s ground-to-air missile 
designed and engineered by Bell Laboratories, illustrated another aspect of 
the integration problem: interservice disagreement on mission and doc¬ 
trine. The Nike system had two versions: a short-range Ajax and a 
medium-range Hercules. These were essentially point defense weapons — 
groups of about ten missiles had their own sets of radars — one set for 
surveillance, one for target tracking and one set for missile tracking and 
guidance. Conceptually, the Nike could be placed on target by signals 
directly out of SAGE, but the Army, reluctant to relinquish control of its 
weapons, developed a coordination center called the “Missile Master” 
which would designate targets to Nike. The Air Force was opposed to the 
Missile Master, arguing that direct integration with a coordinated system 
like SAGE was essential in a situation in which several weapons might be 
brought to bear on a target and which would result in fratricide. The 
Army’s reluctance to integrate with SAGE finally manifested itself in an 
argument about the bit rate that could be reliably transmitted over phone 
lines connecting the Nike system to SAGE. The Army claimed that 750 
bits per second was the proper transmission rate. The SAGE system had 
adopted a bit rate of 1300 bits per second, which could easily be converted 
into 750 bits per second for directing the Nike batteries. Elaborate argu¬ 
ments were made on both sides about whether or not the translation was 
feasible. After some years of haggling, it was decided that it was possible, 
and SAGE control could extend to the Army missile battery level. 

At one point during the disagreements between the Army and Air 
Force, I found myself as the Lincoln representative to an Operational 
Employment Plan meeting for Nike. A group of five or six of us from 
Lincoln and from the Army assembled at Colorado Springs for two weeks. 
An Air Force colonel was in charge. The colonel would start every 
meeting by providing minute descriptions of the symptoms of his ulcer, 
which seemed to correlate with the amount of haggling done the previous 
day. After the two weeks, he had added colitis and enteritis to his list of 
maladies. He felt sure that his career would come to an end with the 
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publication of the proposed plan, which would show that the Air Force had 
had to compromise, but this did not deter him from taking advantage of 
happy hour at the Officers Club every night. By the end of the two weeks, 
however, we had a workable plan. 

The air defense system, as it was laid out prior to the advent of 
SAGE, had concentrated on a ring of heavy radars around the northern, 
eastern and western perimeters of the country. Nevertheless, the 
approaches from the sea were especially vulnerable. A bomber, flying low 
over water, could be almost on target by the time it was detected. 
BOMARC’s effectiveness would be vastly improved if there were some 
way to detect targets at long range. The Airborne Early Warning and 
Control planes (forerunners of AWACS) attempted long-range detection, 
but, because they relied on voice or teletype warnings, were not very 
effective. 

It was not until the AEW&C planes were connected with SAGE 
through the Airborne Long-Range Input program, which was established 
at Lincoln initiative, that it was possible to automatically report targets 
from the aircraft to the ground network. Another solution to the low flyers 
was the creation of the Texas Towers — heavy radars on platforms about 
one hundred miles off the coast. Three such towers were built on the 
continental shelf off the East Coast. These sites had heavy radars, height- 
finders, ground-to-air radio, and other detection equipment found at the 
manual sites, and were connected into the ground network. Eventually, the 
Texas Towers were abandoned after one of them was destroyed in a storm. 

Not only were there problems integrating weapons like 
BOMARC or Nike, there was a new family of manned interceptors to be 
tied in as well. The F-106, an advanced supersonic air defense aircraft, 
was integrated into SAGE in the late fifties. The F-106 had a computer on 
board which allowed it to fly the mid-course under its own control rather 
than having to rely on vectoring instructions from the ground. The F-106 
still had to be told the target location, but with that information, it could fly 
itself near the target, lock on its radar, and complete the final phase of the 
interception. 

Each direction center was tied by phone to its combat center and 
there were phone line connections for cross-telling information from one 
direction center to another. Each radar was connected to at least two 
direction centers. This made it possible to pass hostile target data from one 
sector to another without losing the target. It also provided backup in case 
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one direction center was knocked out. In that case, another sector’s control 
center could easily pick up the responsibility by utilizing radar data from 
the adjacent sector’s radar. 

Not only did all U.S. direction centers have to be integrated with 
SAGE, but a plan had to be developed to deal with the integration of both 
the Canadian radars and the Ottawa direction center which Canada was 
contributing to the U.S. effort. A joint project, called CADIN (Canadian 
Air Defense Integration), was established to connect the Canadian radars 
to the sectors within the U.S. The NORAD connection with other combat 
centers and the new evolving ADC operation center at Colorado Springs 
also presented integration problems which required centralized design 
control. 
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CHAPTER 32 


AIR FORCE REACTION AND THE BEGINNING OF MITRE 


I he Air Force reacted to the integration pressures and problems 
with a series of organizational changes. The first of these changes was the 
creation of a group called SWIG (SAGE Weapons Integration Group). 
This group was composed of representatives from the Air Research and 
Development Command and engineers from the weapons contractors’ 
organizations. SWIG’s job was to specify the changes required in SAGE 
because of new surveillance, weapons or sensor systems, and to make it 
possible for them to work with SAGE. In 1957, SWIG was tentatively 
established at Elanscom Field under Colonel Richard S. Carter. Colonel 
Carter was suffering from glaucoma, and he was afraid of deterioration of 
his vision. He had genuine difficulty in doing preparatory reading, so he 
depended on one of his captains, Brian Hastings, to run his organization. 
Colonel Carter set himself up in an SDC Butler Building with Captain 
Hastings and a secretary. I spent time with him estimating what he would 
need to do his job for SAGE. The gist of my message to him was that 
without technical help and without real rapport with the Air Defense 
Command planners, he didn’t have a chance to carry out his objectives. I 
think that I offended him, but at the same time convinced him that he didn’t 
have the organizational clout to make a go of it. 

There was a strong feeling among those involved with SAGE that 
it was impossible to modify the system from outside; that weapons integra¬ 
tion was a natural part of the continuing SAGE systems engineering job; 
and that SAGE would be under constant evolutionary change. It was 
generally agreed that there ought to be a central organization that coordi¬ 
nated and ultimately signed off on these changes. This organization would 
require more than just ARDC participation, and would, in fact, require 
participation of the ADC and AMC as well. 

After less than a year, it became apparent that SWIG was unable 
to establish itself or to get the needed technical support from the weapons 
contractors. SWIG was replaced with an organization called the Air 
Defense System Management Office (ADSMO), which consisted of rep¬ 
resentatives from three branches of the Air Force, and was headed by 
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Colonel C. A. Thorpe of AMC. Thorpe was a good-natured, hard-working 
man who had little experience in the development business. His concep¬ 
tion of the management office was that of a coordinating agency for all the 
proposals made by the organizations involved in integrating with SAGE. 

Thorpe was a real character. He was likable and energetic. He 
would give long convoluted speeches about his coordination solution to 
the integration problem. On one memorable occasion, Thorpe invited the 
supervisors of the Lincoln Laboratory people who were supporting him, 
plus some RAND people, to his command post room, which had a U- 
shaped table facing a large motion picture screen. He proudly proclaimed, 
as he commanded the screen to roll and unroll by remote control, that he 
had all the tools, and he was ready to take on the problems of air defense 
integration. 

The ADSMO mission was not very well integrated with the 
missions of other parts of the Air Force, so Colonel Thorpe set about the 
task of informing the other ARDC divisions of the ADSMO mission. I was 
invited to accompany him to the Eglin test range in the Florida panhandle 
to help him spread the word. Thorpe and I had worked out a pitch where 
Thorpe described the mission of ADSMO and I described how the Lincoln 
technical support was structured and what it did. The two of us would field 
questions, presumably about conflicts that might arise from the division of 
the work. Thorpe was a pleasant companion: good-natured, loquacious, 
folksy. He liked to talk about retiring to his native Kentucky and whiling 
away the hours under his walnut tree. 

I was not thoroughly satisfied with the understanding of the parts 
that the two of us played in this “show and tell” exercise. I had a mild cold, 
so I was not as sharp as I would like to have been. We arrived at Eglin near 
evening, and were assigned quarters at the base. Because of my equivalent 
rank, we were assigned to a general officer’s quarters. There were two 
beds in the suite, separated by a partition. I was tired, and because I had 
signed up to take a helicopter in the morning from headquarters at Eglin to 
Santa Rosa Island where the BOM ARC launch pads were set up, I wanted 
to get to bed early. Thorpe was a night person, so I got to bed later than I 
thought I should. My situation was exacerbated by the fact that Thorpe was 
the noisiest sleeper I have ever encountered. He had a repertoire of snorts, 
gurgles, and chain-saw imitations. It was impossible to get to sleep. By 
early morning I couldn’t stand it anymore, so I tried to have him roll over. I 
woke him up, but before I could tell him what was wrong, he jumped out of 
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bed, fully refreshed, and wanted to go to breakfast. I didn’t see any point in 
pressing for more sleep because I had lost the skill. I sat bleary-eyed 
through breakfast and took the shuttle to the helicopter pad. I had never 
ridden in an open helicopter before and the noise numbed all my ear 
nerves. I stumbled around the BOM ARC launch pad and watched them 
erect the BOMARC for firing, all the time being aware that I couldn’t hear 
a thing, and climbed back into the helicopter. When I got back, I found 
Thorpe in the room that had been assigned for our briefing. The com¬ 
mander at Eglin said something which I couldn’t hear, but I gathered it was 
a polite introduction from the practiced smile that he gave to Thorpe when 
he introduced him. I didn’t hear what Thorpe said either, so I missed my 
cue and was dozing off on one of the front seats facing the commander. I 
gathered from Thorpe’s gestures that it was my turn, so I got up, only to 
find that a small speech was to be made by the local chief scientist. I was in 
a panic, and didn’t want to cause any more embarrassment, so I made sure 
that I was to speak next before I got up again. I couldn’t hear a thing. I was 
stopped by hand signals every once in a while when someone asked a 
question. Thorpe fielded the questions since I couldn’t read lips. I finally 
went through all of the points that I wanted to make and sat down. Thorpe 
came over and shook my hand. I could make out from his reaction that we 
had made a hit with the Eglin folks, and we were then whisked off to the 
airport to an old DC-3 which was fitted out to be used by colonel-level 
commanders for their transportation. 

Thorpe apparently sincerely believed that I had done a good job, 
because he made a point of praising my performance whenever the topic of 
organizational integration came up. It was because of incidents like this 
that I felt that I had lost my ability to evaluate my own performance, and I 
decided no one needed to know how confused I had been. I decided that 
success was not necessarily related to performance and I took credit for 
this fortunate accident. It balanced off the times when my performance 
was good but the audience didn’t like it. 

About the time ADSMO was created, negotiations were taking 
place between James J. Killian, Jr., then president of MIT, Julius A. 
Stratton, MIT provost, and James H. Douglas, Jr., secretary of the Air 
Force (assisted by George Valley), to find an organization to take over the 
system engineering for the SAGE system. 

The Air Force had tried a number of techniques for providing 
technical support for the integration problem. They had talked about 
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industry combinations for support or about giving the task to a single 
company, and to eliminate conflicts of interest, restricting what that com¬ 
pany could manufacture for the system. Under Douglas, the Air Force 
approached Bell Laboratories and Western Electric to see if they would 
take over the job. Bell and Western declined the offer but did agree to 
continue with the work they had been doing with ADES. They felt, 
however, that the central design and system engineering role ought to 
remain with Lincoln. 

Misgivings were expressed by those organizations that had been 
approached by the Air Force for the job, among them RCA. While the 
manufacturers were willing to do the job, they were not willing to accept 
the restrictions that went along with it; that is, the exclusion from bidding 
on the hardware that would result from the SAGE modifications. Also, the 
idea of expending their best people on a job with so little financial leverage 
did not appeal to them at all. 

While these possibilities of private industry sponsorship were 
being explored by MIT and the Air Force, Bob Everett and I were asked to 
talk with organizations that were interested in applying for the task. I 
remember a meeting we had with Jordan Baruch of Bolt, Beranek and 
Newman, one of the profit-making companies, about Jordan’s conception 
of how the job would be done. He described a concept in which participat¬ 
ing organizations would assign their most valuable engineers to a group. 
This elite group would continuously receive motivational training which 
would supposedly keep it unified and concentrating on the job at hand. The 
notion struck Bob and me as weird and inoperable. 

Given the overall lack of interest by profit-oriented industry in 
completing the SAGE engineering job, MIT and the Air Force began 
thinking in terms of setting up a non-profit organization. The job of 
defining such an organization was given to Jim McCormack, then vice 
president of MIT, who had recently retired as a major general from the Air 
Force. McCormack was fresh from setting up the Institute for Defense 
Analyses, so establishing what would eventually become the MITRE 
Corporation was a natural assignment for him. 

A West Point graduate and a Rhodes Scholar, McCormack had 
been active in atomic weapons development while in the Air Force. A 
heart attack had forced him to retire. At MIT, he had taken Admiral 
Edward Cochrane’s place as the vice president in charge of the defense 
work that MIT was pursuing. He was known for his striking resemblance 
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to Edward VIII, the Duke of Windsor, who abdicated the British throne in 
1936. McCormack had a tremendous capacity for consumption of martinis 
at lunch. I had been at luncheons with him where he consumed three or 
four martinis without any visual effects. He could also ad lib summaries of 
complicated conferences. At one point, there had been a space symposium 
at a Boston hotel, organized around approaches articulated by Werner von 
Braun. Jim sat through the presentations, and after lunch on the last day of 
the symposium, he was asked to summarize what had gone on — this, after 
having consumed his martini ration. He got to his feet, and, without notes, 
delivered a thorough yet brief summary of most of what had been said. I 
remember telling him that I had enjoyed his summary, and I asked him 
how he had decided what to say. He responded by telling me that he didn’t 
know what he was going to say until he said it. 

During this period there were several challenges to the concept of 
developing a not-for-profit organization; most notably, the examples of 
other companies which had been established for this purpose and had 
eventually run into trouble. On the other hand, there were successful not- 
for-profit organizations like RAND, and the newly formed System Devel¬ 
opment Corporation (SDC). SDC, in fact, felt that they were the natural 
choice for the SAGE system engineering and integration job. They had 
responsibility for the master program and were connected with ADC 
through both the training and programming products. McCormack had 
several discussions with the SDC/RAND board, but decided that it would 
be important to include in the new organization the people who had 
worked on system engineering at Lincoln, since they would have back¬ 
ground on all facets of the system. As a step in that direction, I was asked 
to prepare the first draft of the work statement for the contract which 
defined, in general terms, the function of the not-for-profit organization. 

It finally came down to a choice between the not-for-profit 
SDC and creating a new not-for-profit company. The Air Force, growing 
increasingly concerned about the SAGE integration problem, felt that 
Lincoln people, because of their familiarity with the program, should 
be involved. In May, 1957, Brigadier General I. L. Farman and Colonel 
Gordon T. Gould of the ARDC System Management Office at Wright- 
Patterson visited Carl Overhage at Lincoln. General Farman had gotten the 
word that Secretary Douglas favored the use of Lincoln people, and had 
come to find out from Overhage if Lincoln would do it. Bob Everett and I 
were both at this meeting. It was determined that another meeting should 
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be held, at which the choice between SDC and a new not-for-profit 
organization would be made. 

The follow-up meeting included Bob and me, Overhage, Colo¬ 
nel Gould and other colonel-level people responsible for electronic sys¬ 
tems at Wright-Patterson, and M. O. Kappler from SDC. Colonel Gould 
arrived early to make arrangements with Overhage to use a Lincoln 
conference room for the meeting. We were all assembled except for 
Colonel Forrest G. Allen from Wright, who arrived a little late. Colonel 
Allen was a spit-and-polish colonel who smoked cigarettes using a foot- 
long cigarette holder which he carried like a riding crop. He strolled into 
the meeting and draped himself across several chairs. His arrival was a 
signal to begin the meeting. During the first part of the meeting, Everett 
was asked to describe the potential organization. He emphasized that the 
organization should include both hardware and software as well as enough 
research and development capability to verify designs and to increase the 
validity of projections. The proposal essentially described the operating 
concept used at Lincoln. 

We broke for lunch. Kappler didn’t eat anything in order to be 
sharp when he was scheduled to speak. After lunch, when we returned to 
the conference room, Kappler made his pitch that the system could be 
controlled by the designs of the computer programmer, and that hardware 
and design verification could be done by others. Following Kappler’s 
speech, there was a disjointed conversation which avoided direct reference 
to the selection. Colonel Gould said something about how productive the 
meeting had been. Colonel Allen smoked his last cigarette and stuffed his 
cigarette holder into his briefcase. Overhage made a noncommittal speech, 
declaring everyone was happy. Bob and I looked for a consensus but were 
unable to find one. We went away feeling empty. Sometimes it happens 
that way. 

Kappler was counting heavily on getting the SAGE system engi¬ 
neering job. As president of SDC, he was responsible for employing a 
large number of system programmers, and he desperately needed work to 
follow the SAGE programming job. He took the position that if he couldn’t 
be given the job sole-source, he would have to compete with private profit¬ 
making companies, which in fact he began to do soon after the meeting. 
He eventually pitted himself against his own board on that subject, refus¬ 
ing to limit himself to what could be given him sole-source by the govern¬ 
ment. He tells the story about meeting Bill Golden, his board chairman, on 
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what he thought was a routine trip from the airport. He was given the news 
by Golden that he was to be replaced by Wesley Melahn, and was given a 
termination settlement. Within a year or so, the board concluded that 
Kappler had been basically right, and that SDC ought to become a profit¬ 
making corporation and compete for work like any other profit-making 
operation. When this information got back to Kappler, he told me that his 
first reaction was to hire a sky-writer and have him write out, “I told you 
so!” directly over Golden’s office in Manhattan. 

The board eventually felt that Wes Melahn did not have the 
necessary experience in the private sector. The story was, that acting with 
typical insensitivity, they advertised for Melahn’s replacement in the New 
York Times , which was how he learned of their decision. 

Between the Air Force headquarters (including the secretary of 
the Air Force) and MIT management, a decision was finally made to 
establish a new not-for-profit company to carry out the tasks spelled out in 
the work statement that Bob and I had prepared. As a peace-making 
gesture to SDC, several members of the SDC/RAND board would be 
invited to become board members of the new company. 

As part of the package negotiated by MIT, it was agreed to 
upgrade ADSMO and to put it under the direction of Major General 
Kenneth P. Bergquist, with an ADC component headed by Brigadier 
General Loren McCollom and AMC’s Major General Clyde H. Mitchell. 
In the interim, Lincoln Division 6 would provide temporary support to this 
newly formed Air Defense Systems Integration Division (ADSID). 

General Bergquist came from ADC headquarters, and had had 
considerable experience in air defense. He was in Hawaii as part of a radar 
squadron, and it was his radar that should have provided tactical warning 
of the Japanese attack on Pearl Harbor. He had been through the post¬ 
mortem Pearl Harbor investigation, and didn’t want anything like that to 
happen again. He had a deputy for engineering, a Colonel Wilfred H. 
Tetley, who would have liked to have been a scientist, and whose office 
blackboard was always covered with Greek symbols and equations with 
which he tried to defend himself from the Lincoln crowd. Tetley was given 
the job of interfacing with MIT management, and from his point of view, 
what MIT did was subject to his direction. He had been in Hawaii with 
General Bergquist, and had been traumatized by the investigation. I was 
his MIT counterpart, and he used to come around and complain that he was 
being ignored by Lincoln. The Lincoln people were used to ignoring 
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bureaucratic reporting procedures and Tetley used to try to get my atten¬ 
tion by bending my ear on the mathematics that were the basis of the SAGE 
radar and computer operations. When he found that I was not responding 
with proper enthusiasm, he would mix his lectures with descriptions of the 
horrors of being a retired colonel who could at any moment be jerked out of 
retirement to attend his own court-martial! I always felt that Tetley should 
have been a mathematics teacher. 

ADSMO was a short-lived organization which devoted much of 
its effort to the planning rather than to the implementation of its functions. 
Its original charges were to oversee the integration of the various compo¬ 
nents of the air defense system and to plan for the future evolution of the 
system. With ADSMO receiving this comprehensive charge, the ADES 
office, originally designed to be the coordinator for the various organiza¬ 
tions involved in the air defense task, saw a reduction in its scope: ADES, 
combined with the Electronic Defense System Division, was now called 
the 216L Project Office and was to handle only the ground electronic 
portion of the air defense system. It was placed under ADSMO, rather than 
under the Air Force Cambridge Research Laboratory. Without any link to 
what was going on at Lincoln, ADES was at a technical loss. Thus, ADES 
requested and received, with much appreciation, a cadre of knowledgeable 
SAGE people from Lincoln (under Jim May from Division 6) collocated in 
New York. 

At the same time, the definition of ADSMO’s role and the scope 
of its concern continued to expand to the point where many Air Force 
people thought it should report to Air Force Headquarters rather than to the 
ARDC. They thought it needed this higher-level connection to cover the 
management, development and procurement of weapons and systems as 
well as of the electronic ground equipment. This thought was given some 
emphasis as negotiations proceeded. The model for this special connection 
with headquarters was drawn from General Bernard A. Schriever’s Ballis¬ 
tic Missile Division on the West Coast. But General Schriever’s bypassing 
of ARDC headquarters had caused enough friction in the Air Force so that 
people were hesitant to do it again, especially since by now General 
Schriever himself was a three-star general and head of ARDC (later called 
Air Force Systems Command). He had responsibility for ADSMO as well 
as for the Ballistic Missile Division and the Aeronautical Division at 
Wright Field. Schriever took over many AMC functions, among them 
development and systems acquisition. 
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Schriever was opposed to placing ADSMO directly under Air 
Force Headquarters control, and ultimately, ADSMO was placed under 
Air Force Systems Command (AFSC). Schriever was a man who got his 
way. His strong physical presence (he had a well-built, well-tanned, 
immaculately groomed 6'4" frame, and was an excellent golfer), com¬ 
bined with his political expertise and connections, made him a formidable 
adversary at the internecine competitions, where he won most of the 
contests. Under AFSC, ADSMO became ADSID, headed by General 
Bergquist. In the course of the negotiations regarding ADSMO’s reporting 
level, Bergquist had argued very strongly for the connection to Air Force 
Headquarters, and because it was at cross-purposes with what Schriever 
wanted, Schriever placed his own man, Brigadier General Charles H. 
Terhune, as the vice commander of ADSID. Terhune later became deputy 
commander of ADSID’s successor, the Command and Control Develop¬ 
ment Division (C 2 D 2 ). C 2 D 2 became the Electronic Systems Division, and 
as a major general, Terhune was its second commander. 

Bob Everett and I were at this point the senior technical people 
left on the job. In mid-1958, Overhage and McCormack nominated 
“Hap” Halligan as president of the new not-for-profit corporation. He was 
the director of military engineering at Bell Laboratories and had been on 
the CADS program and on the Bell/Westem portion of the SAGE task. 
Halligan was an experienced Bell Laboratories man in his late fifties. He 
had been a source of support to the SAGE system in his ADES role, and 
Overhage and McCormack chose him because of his maturity as well as 
his Bell Laboratories background. Hap was endorsed by the initial MITRE 
board under Rowan Gaither, who was to die of cancer prior to taking any 
effective role in the management of MITRE. 

Everett and I were asked to become the technical director and 
associate technical director of the new company in October, 1958. We both 
accepted. The other 270 people from Lincoln Division 6 were targeted to 
join in January, 1959. In order to get the company started, it was decided 
that MITRE, as the company was named, would be given a $13 million 
startup subcontract from MIT for the first six months of operation. Bob 
Everett and I drafted the work statement for this subcontract, which was 
based on the proposal we had drafted earlier. 
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CHAPTER 33 


HALLIGAN 


When Halligan was named president of MITRE, it was well 
known that Jay Forrester opposed the selection. Halligan invited Jay to his 
office, and also invited Bob and me to sit in, to talk over Jay ’s objection. 
Jay, in his usual straightforward way, said he felt that whoever took on the 
job of president would have to be totally committed to it, and he ques¬ 
tioned Halligan’s dedication, since Halligan had taken only a leave of 
absence from Bell Labs to become president of MITRE. Halligan noted 
the fact that he had a stake in Bell Labs’ retirement fund, and protested 
Jay’s objection. He did not see why this would be an impediment. After 
some minutes of reiterating their respective views on the subject, Halligan 
asked Jay if it had been his desire to have the job, thinking Jay might have 
felt it ought to have been offered to him. Jay, in his characteristic manner, 
told Halligan that the industrial dynamics program he was creating at MIT 
was infinitely more useful than anything the new MITRE organization 
might create. Jay did not mention the looming legal battle with IBM for the 
patent to the random access core memory — and the time and effort he 
knew it would take to ensure a favorable outcome. 

Halligan was a good-natured, easy-going man of good reputation 
who was used to managing in the conservative style of the Bell System. He 
tended to favor the status quo and avoided controversy, especially in 
dealing with the MITRE board and with the Air Force. At Bell, Halligan 
was used to having the power of the organization above him. But at 
MITRE, the power of the organization was below him, and those holding 
the power were on the average of 10 to 20 years younger than he. It was 
awkward for him to delegate without delegating his whole job, especially 
since he was bedeviled by criticisms of the stubborn, independent “Lin¬ 
coln clique.” In an effort to bring in new blood, he hired a retired Air Force 
lieutenant colonel, Peter Schenk, as executive vice president. But he never 
gave Schenk any real authority. This situation lasted about a year, until it 
became clear that Schenk could not justify his position, and he eased 
himself out. MITRE used him as a consultant for a little while. 

I believe Hap felt he was being supportive of the organization 
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he inherited from Lincoln, but couldn’t find a solution to relieve the 
pressure of the criticisms. I liked him, but was always distressed by what 
came across to us as a lack of support. My own relationship with Halligan 
was colored by the apparent attitude he held toward us — one of resigna¬ 
tion rather than encouragement. With me, it centered on my communica¬ 
tion skills with outsiders, particularly briefings to the Air Force. All of my 
activities were devoted to developing a program with the Air Force and 
planning projects that met their needs. I had a natural tendency toward 
stage fright, of which I was aware, but which I had overcome, or so I 
thought. My communication with large groups was good, I felt, but I 
needed the encouragement of our management, which Hap witheld. I 
would prepare speeches that were good in my opinion, but dry runs with 
Hap would cast a cloud of doubt. Hap would say, “I don’t like it,” but 
wouldn’t explain. This resulted in my being overwhelmed by stage fright, 
and caused me to fumble the first few lines of my talks, only confirming 
Hap’s judgment. It got to the point where a professional speechwriter and 
communications expert was hired to teach us, especially Everett and me, 
not to mumble or otherwise give bad speeches. We had come from a 
culture that was content-oriented (MIT), where use of communication 
aids, such as view-graphs or slides and slick presentations, were somehow 
suspect, and where speaking from notes scribbled on the back of an old 
envelope was considered a virtue. Hap and I never resolved this difficulty, 
which only got worse with time. 

Needless to say, Everett’s response to Halligan was as the subor¬ 
dinate who held all the chips. This put Halligan in a position where he 
would have to justify changes in organization or direction, rather than 
allowing himself his prerogative of rank — namely, the right to be arbi¬ 
trary. This isn’t to say that Everett was disrespectful or insubordinate, but 
he required too much justification to be brushed off, and Hap didn’t have 
the energy for the work that would be required to resolve the issues and 
take personal control of the situation. From outward appearances and 
socially, they were quite compatible, but repetitions of these encounters 
prevented Halligan from endorsing Everett by recommending him for 
membership on the board. He did, however, change Bob’s title from 
technical director to technical vice president. 

To his credit, Hap managed as MITRE’s first president for eight 
years, during which time the company developed and adapted to the new 
problems with considerable success. He broadened the reputation of 
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the company in the communications field, where he drew upon his knowl¬ 
edge of the Bell System, and he attracted many competent and experienced 
people. Hap also succeeded in providing a mature front for the largely less 
experienced and less polished Lincoln staff. In retrospect, Hap may have 
been the right man for the job, and he probably did more for MITRE than 
my own biased experience with him would admit at the time. 

In spite of the problems that he had in dealing with us, Hap 
established a corporate structure that was well-balanced and thoughtfully 
developed. In particular, he initiated a formal “policies and procedures” 
book that set the limits on the authority and scope of various parts of the 
organization, and he assigned a number of administrative and finance 
people to set the procedures down and coordinate them. Although there 
were some differences of opinion about these policies and procedures, the 
overall effect was to force the management to be open and explicit about 
MITRE operations. 

Shortly after the formation of MITRE and the Air Force’s Elec¬ 
tronic Systems Division (ESD), MITRE realized that its job had drasti¬ 
cally changed from a one-project (SAGE) task to a many-project task. This 
required a new orientation, and a new way of working with the Air Force 
system program offices. There was in particular a problem of dividing 
MITRE effort among a large number of ESD projects, and at the same 
time, ensuring that each project received the best mix of skills. The 
embryonic ESD, in trying to find its niche in the Air Force world, was 
particularly concerned about the nature of support that MITRE would now 
provide. Largely due to Hap’s effort, MITRE negotiated a memorandum 
of agreement with ESD’s commander, Major General Charles Terhune, in 
December, 1962. The agreement spelled out the classes of work that 
MITRE could be called upon to do, and defined system/subsystem engi¬ 
neering, task engineering, and research and experimentation as major 
categories. In addition, it dealt with the technical direction authority, 
which was a joint ESD/MITRE product. It also outlined the parallel lines 
of authority which the MITRE project leaders and ESD project officers 
were expected to follow, especially in the case of disputes, and it defined 
the Technical Information Report (TIR), the formal vehicle for transfer¬ 
ring MITRE designs and technical direction to ESD. The memorandum of 
agreement would be modified in later years to adapt to changing situations, 
but it provided the framework of the MITRE/ESD contract. 

At about this time, the Holifield Congressional Subcommittee on 
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Military Operations was investigating federal contract research centers 
(FCRCs), a group of contract research organizations that had been estab¬ 
lished as not-for-profit corporations (including MITRE, SDC, RAND, 
Aerospace, Lincoln, IDA and others) which supported primarily the Air 
Force in its system development programs. One of these, Aerospace, and 
its president, Ivan Getting, had drawn attention to themselves by having 
the government pay for transporting Getting’s yacht from the East Coast to 
the West Coast, and by Getting’s salary of about $90,000 per year, which 
was double the salary of the congressmen who were now investigating 
Aerospace. Among other things, the investigation resulted in a rule that no 
officer of any FCRC would be paid a salary higher than a congressman’s 
salary (which was $45,000 at the time). At the hearings in Washington, all 
the FCRCs took their turn in describing the nature of their work and their 
relationships with the government. The effort Hap had put into the memo¬ 
randum of agreement with ESD found its place at the hearings, where Hap, 
in a polished, confident and cool presentation, went over these matters 
with members of the committee. We were proud of our appearance before 
that committee. 

After the challenge to the use of FCRCs, Major General Ben 
Funk, commander of AFSC’s Space Systems Division, which had em¬ 
ployed Aerospace, was given the assignment of defining the appropriate 
role that FCRCs should play, and the numbers and kinds of staff that ought 
to be employed. This job was referred to a committee set up by Funk, 
which was known as the Funk Committee. It consisted of Halligan and the 
other presidents from all the FCRCs. Each FCRC tried to define the proper 
role it should play, and tried to define the way the Air Force program 
offices should use them. The Funk Committee report did that to the best of 
its ability, and the book was used as a platform for discussion, seeking to 
make the process of allocation and assignment less subjective. The Funk 
Committe report became the major reference for the many reviews that 
would be made of MITRE’s productivity. 

As part of setting up the organization to work on many projects 
instead of one, it was necessary to establish a way of charging directly 
those funds for the specific projects. The major expense was the charge for 
MITRE staff time, and some way had to be invented for allocating charges 
among the projects. Hap assigned me the task of designing and effecting 
an appropriate time allocation system. Needless to say, this was an onerous 
assignment, in view of the staff’s long tradition of opposing any kind of a 
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time card system. We finally settled on a system in which the allocation of 
staff by project was installed, and each week, the staff member would 
record hours spent on a project and the supervisor would endorse it. It was 
for me one of the most frustrating tasks I had taken on at MITRE. Hap 
didn’t have anything to say about the job I’d done, which I took to mean 
that he liked it. 



CHAPTER 34 


LEAVING LINCOLN AND JOINING MITRE 


In establishing the new organization, McCormack and Overhage 
faced the problem of finding people who both knew the SAGE job and 
would be willing to join the new company. It was logical to them that a 
major part of Division 6, or all of Division 6, ought to form the nucleus of 
the organization. There had already been a sort of rift between Division 2 
and Division 6 on the subject of the control of the SAGE system design, 
and there seemed to be some sentiment on the part of Overhage and the rest 
of the Lincoln Steering Committee that it would be desirable if Division 6 
could be split off from Lincoln so that Lincoln could continue its research 
in its own way. 

By the time of the rift, Division 6 had evolved its own main 
groups. There was a group devoted to operational mathematical specifica¬ 
tions; a group that did programming; a group that did testing of ESS and 
Montgomery, and a Systems Office. There was also a research group, 
under Bill Papian, which was then concentrating on research on the TX-0, 
an all-transistorized advanced computer, which was expected to lead the 
trend in computer design. While the rest of Division 6 opted to transfer to 
the new company when it was formed, Papian’s group chose to stay with 
Lincoln. 

Prior to the transfer, Division 6 had been working with ADSID 
for about a year so the transfer was not traumatic. Those who were already 
working for the Air Force were to continue to work in the same capacity 
(and in the same Lincoln office space) after the transfer. I felt no pangs 
about making the transfer. I thoroughly believed that the new arrangement 
would make it easier to do the integration and overall systems engineering 
job. But, as in many major changes, there remained a certain amount of 
hostility between Lincoln and the part of Lincoln that went to MITRE. It 
took the form of disparaging remarks about the meaning of the acronym 
MITRE. Among the most humorous remarks were these: that MITRE 
stood for “MIT Reject Engineers” or “Must I Trust Robert Everett?” or, 
in reference to the fact that there were a lot of Italians in the support 
groups, “Many Italians Trying to Run Everything.” 
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To celebrate our leaving, the Steering Committee had a dinner 
for us at the MIT Faculty Club. After the dinner, Carl Overhage, director 
of Lincoln Laboratory, spoke. Overhage’s favorite way of handling this 
sort of toastmaster job was to characterize people who were leaving by 
making reference to classical works. This time he referred to Shakespeare, 
and made me Hamlet. I took his remarks to mean that, like Hamlet, I was 
diffident and often paralyzed when the situation called for action. Usually I 
enjoyed Overhage’s farewell addresses, but this time I didn’t. Although I 
was leaving to join the new company, I believed, as Bell and Western 
believed, that Lincoln could have picked up the continuing role of system 
engineering on the air defense system. I made what I now consider an 
indelicate response to Overhage’s talk. I chose to tell a story, a true story, 
about a friend of mine who was an anchorman on a television news show in 
Poland Springs, Maine. He commuted to work every day in a carpool. One 
day, driving particularly fast, he encountered a moose wandering along the 
highway in his lane. Because there was a car coming in the other direction 
and he could not stop in time, he hit the moose. The moose slid over the 
hood, smashed through the window on the passenger side where his 
carpool mate was sitting, and sprayed “moose juice,” so to speak, all over 
my friend’s passenger. When the car came to a stop, the passenger looked 
over at my friend who was laughing about the scene and he said, “My, 
Charlie, you’re taking this wonderfully well.” I concluded my remarks by 
saying, “My, Lincoln, you’re taking this wonderfully well.” As soon as I 
had finished the story I was sorry I told it. As a farewell gift to all the 
departing Lincoln Steering Committee members, we were given anodized 
aluminum trays, the borders of which had a number of Lincoln-head 
pennies with the mint year corresponding to each year spent at the MIT 
Lincoln Laboratory. 

During the period of the transition, Bob Everett spent quite a bit 
of his time ensuring that the retirement benefits which we had accrued at 
Lincoln would be held in effect and could be vested at a later date. During 
the course of that negotiation, Everett managed to get at odds with Joseph 
Snyder, who was vice president and treasurer at MIT, and Bob’s behavior, 
which was characteristic of him, was tenacious and logical, if not insubor¬ 
dinate. Ensuring that MITRE people would get these benefits was an 
additional incentive for joining the company. Bob won the point, but in the 
process alienated Snyder. The retirement issue was one of many similar 
issues too numerous to mention that would have to be dealt with, and 
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and provided adequate opportunity for friction between the new MITRE 
management and MIT. All in all, the friction increased concern about 
giving Everett the position I believe he deserved as an officer of the newly- 
formed MITRE. Instead of becoming Halligan’s vice president, he was 
named technical director. 


* * * 


One of the outstanding things about the Digital Computer Labo¬ 
ratory and Division 6 of Lincoln Laboratory, and I think to a large extent 
the other divisions of the laboratory, was the esprit de corps — the spirit 
that pervaded the operation. Everyone had a sense of purpose — a sense of 
doing something important. People felt the pressure and had the desire to 
solve the air defense problem, although there was often disagreement as to 
how to achieve that end. Energy was directed more toward solving indi¬ 
vidual problems, such as making a workable high-speed memory or a 
usable data link, than it was toward solving the problem of the value of the 
finished product. It was an engineer’s dream. The responsibility for 
achieving that end was liberally distributed among the participants. I know 
that I felt the need to do something useful at every level of responsibility 
that I held. 

Today, Jay Forrester feels the reason for this spirit was the 
reward/punishment system that was operating. In most organizational 
situations, there is a high penalty for failure and a low reward for success. 
In the Digital Computer Laboratory and Division 6, the opposite was true: 
there was a low penalty for failure and a high reward for success. People 
were willing to try things out and fail, and try again, without the devasta¬ 
tion that comes as the high penalty for failure. It was an ideal climate for 
bringing out the best and the greatest number of ideas in working groups. 
Not only was this relationship between reward and success operating, 
there was also the feeling that each engineering problem should have one 
or two backups to ensure the success of the enterprise. Typical of this was 
the core memory backup for electrostatic storage. There was also a lot of 
attention paid early on in the development of any part of the system to its 
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eventual upgrading and replacement. This attention actually sped up the 
process of acquiring new and extended capabilities for the system. 

In addition to this philosophy, a high degree of confidence in the 
MIT people was shown by the administration. We were often told about 
Nat Sage, the principal man in the MIT administration who shaped MIT 
contracting policy. He set up regulations and procedures that were deliber¬ 
ately ambiguous which could be interpreted by the contracting officer to 
meet the needs of the situation. Sage would insulate the people working in 
the laboratory from the nitpicking of the customer. 

The transition from Lincoln to MITRE occurred in stages from 
1958 to 1960. The biggest group transferred on January 1, 1959. The 
Lincoln people generally believed that the success they had at Lincoln was 
due in large part to the fact that they could take the initiative in making 
technical decisions. They wanted the same freedom at MITRE. They 
wanted to be able to tackle systems problems as a whole as they had done 
while at Lincoln — to decide how much planning and analysis ought to be 
done, how to allocate their resources, and the like. 

This need for autonomy on the part of the MITRE staff was at 
cross-purposes with the desire of the Air Force to take on the responsibility 
for the design and management of procuring the system. Much effort was 
expended by ADSID people to get control of the MITRE program. In 
oversimplified terms, the desire of people at the System Program Office 
(SPO) was to obtain manpower from MITRE they could not otherwise 
acquire through military and civil service sources. In the extreme, the SPO 
wanted to be able to individually select and integrate into their organiza¬ 
tion MITRE people for the project. 

Doing design verification — building breadboards and brass- 
boards — was another area of disagreement between MITRE and ESD. 
MITRE people thought it important to be able to do design verification to 
prove the feasibility or utility of designs of which they were not quite sure. 
Design verification also fulfilled another need: it kept the staff current in 
the state of the art so they could make judgments about the proposals the 
industrial contractors prepared. The System Program Office most often 
looked to other contractors to provide these proofs of performance. They 
wanted MITRE to do primarily administrative work. From their point of 
view, the same budget could provide for more people to do administrative 
work than hands-on work because of the cost of the facilities required. 
Nevertheless, MITRE managed to get an agreement that at least 10 percent 
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of their work would be hands-on. The MITRE people thought a better ratio 
would have been a third or more, depending on the particular problem they 
were addressing. 

There was also a resistance to overplanning the use of the 
MITRE staff, since it was a belief at both Lincoln and MITRE that 
problems cannot be predicted accurately before trying out the design, and 
that it is important, especially in system engineering, design control and 
design verification, to be able to accommodate problems as they might 
arise. For a time, MITRE people refused to divide a job into subtasks, on 
the grounds that it would allow for more rigid allocation of resources and 
thus preclude the adaptation which would be required to meet the real 
problems as they came up. However, MITRE did agree to reporting, after 
the fact, on the cost of the actual jobs which were done. Eventually, 
MITRE and SPO came to terms with plans that were broad enough to 
accommodate the necessary changes as time progressed, but sufficiently 
defined to outline what MITRE was to accomplish during that period. 

The concern on the part of MITRE people continued to manifest 
itself in such things as resistance to the introduction of time cards and the 
use of stickers on car bumpers which were a pass to the Hanscom Air Base, 
because of the implication that the Air Force was fine-tuning its control 
over MITRE resources. In some parts of the Air Force, there was a drive to 
govern precisely what should be done on a MITRE project, and to monitor 
MITRE expenditures. This monitoring eventually led the Air Force people 
who were responsible for MITRE contract management to do helicopter 
surveys of the MITRE parking lots at various times during the day to verify 
attendance. We were used to the MIT philosophy that quality of time on 
the job was more important than attendance. We agreed, after considerable 
harassment, to do the monitoring ourselves. We also agreed on a standard 
time sheet that reported an individual’s time on a project-by-project basis. 
We finally settled the issue by suggesting to the Electronic Systems 
Division that those Air Force people who were stationed in the MITRE 
buildings, and whose attendance was less than perfect, be treated in the 
same way that MITRE treated its staff. We proposed that the military 
people, as well as MITRE people, use a standard time sheet. We said that 
when MITRE staff members came in late, they would be asked to make a 
visit to the Division Office to explain their lateness or lack of time spent on 
a project. The military people, at the same time, would report in a similar 
way to their deputies. We proposed that this was only fair, and that the 
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symmetry of the proposal would prevent attendance information from 
being used by either the military or MITRE people as leverage in local 
squabbles. This broke the back of those who were bent on fine-tuning the 
contract control. After we presented our “symmetrical” proposal, the Air 
Force dropped both the surveillance and the subject. 

The attitude that led to these situations was pervasive, and 
prompted an Air Force investigation of the situation by a Colonel Hunn. 
Hunn naturally felt that there ought to be a SAGE budget that broke down 
into areas of work and their respective costs and schedules. It was my job 
to convey to him the MITRE philosophy — which was that we would tell 
him the budget after the fact. Although some officers were incensed by the 
MITRE position, Hunn took a more permissive attitude, and he listened 
sympathetically to our explanations and the crude way in which we han¬ 
dled the SAGE budgeting. His patience paid off in our eventual restruc¬ 
turing of the contracting policy, and in the institution of the TO&P — 
Technical Objective and Plans — a document that spelled out the bound¬ 
aries of the projects but that allowed for trade-offs among them. 
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CHAPTER 35 


FROM SAGE TO BUIC 


During the time that MITRE was getting established, several 
things were happening that were lowering SAGE priority. Internationally, 
there was the growing awareness that the Russians were concentrating on 
ballistic missiles rather than on aircraft. This concentration on ballistic 
missiles for strategic offense by the Russians was underscored by the 
launching of Sputnik in 1957, and the growing perception that there was or 
may have been a missile gap. The Air Force emphasis changed from 
defense to offense (deterrence) and from aircraft to intercontinental ballis¬ 
tic missiles, and the budget for these missiles competed for funding across 
the board. 

At the same time, SAGE was being criticized as overexpensive, 
and the charge was levelled that SAGE was “gold-plated.” The cost of 
SAGE had escalated far beyond the early estimates of the project, and for 
the first time, the costs of the project were seriously being questioned. It 
had seemed that the cost of the system had increased greatly during the 
course of its development. However, the Air Force claimed that it was a 
“bookkeeping” increase. They maintained that the increases were due to 
the broadened scope of SAGE, from its original definition of computers, 
data processors and digital communications to be added to an existing air 
defense system (on which the original estimates were based) to the entire 
air defense system, including radars, ground-air communications, all 
point-to-point communications, command headquarters, and so on. But 
the President’s Scientific Advisory Committee, set up to examine air 
defense, was seriously critical of many air defense expenditures, and the 
newly formed Deputy Director of Defense Research and Engineering 
(DDR&E) under Herb York and his deputy Hector Skifter began to ques¬ 
tion the cost-effectiveness of the whole operation. Also during this period, 
a committee headed by John Klotz was formed by the Department of 
Defense and DDR&E to investigate the SAGE system. The Klotz Com¬ 
mittee was essentially a data-gathering organization. It was obvious that its 
charge was to cut down the scope of SAGE by examining all aspects of the 
system. 
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Shortly after the first SAGE sector became operational in 1958 at 
McGuire, SAGE began to lose much of its support. As a consequence, the 
overall distribution of SAGE sectors was continually being decreased, and 
the plans continued to include manual sites as part of the U.S. air defense 
program. The SAGE plan of an attrition system of defense, which would 
provide uniform coverage over the continental U.S., began to slip back 
into the perimeter system of defense, which relied on radars primarily 
along the northern border and the East and West Coasts. 

Another criticism of SAGE was that the direction centers, 
located on SAC bases, would be bonus targets in the event of an attack on 
SAC. Around 1957, Lincoln had been developing the concept of a system 
known as the Super Combat Center (SCC). This system concept included 
placing the direction centers in deep, underground facilities which would 
be even more centralized and have a broader area of coverage than the area 
direction centers. To make this system more palatable and more cost- 
effective, the plan included the idea that air traffic control in the United 
States would be merged with the air defense and share the radars of both 
systems. At least one facility was built, in Montana, where the en-route 
traffic control center was integrated in the same building as the air defense 
direction center. The SCC concept was also broadened to include some of 
the functions that had previously been thought to belong to the National 
Military Command System, such as strategic warning. Also included in 
the SCC concept was a plan to upgrade the computers; the FSQ-7 was 
expected to be replaced with the FSQ-32 computer, a transistorized 
machine. 

In 1959, the SCC plan was turned down. Critics of the system 
had pointed to its vulnerability to nuclear attack, as well as to the overly 
conservative design of the system, which required back-up on all critical 
communications and processing, the tremendous air conditioning load, 
and the special, expensive lighting arrangements required for the cathode 
ray tube displays. When the SCC program was cancelled, the FSQ-32 was 
modified for SAC use in the SAC control system. 

The first connection between air traffic control (ATC) and SAGE 
was established before SAGE was bom. In 1949, the Air Force’s Watson 
Laboratory signed a contract with the Digital Computer Laboratory to 
investigate the feasibility of using a digital computer as the control element 
in an air traffic control system. The work under this contract led to the 
connection between AFCRC’s MEW Digital Radar Relay and Whirlwind, 
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and to the first track-while-scan processing of digitized radar data by a 
digital computer. These techniques and experiments were the early foun¬ 
dation of what later became SAGE’s radar processors and trackers. In 
1957, the government requested a proposal from Lincoln for an air traffic 
control system that would use many of the same kinds of equipment and 
techniques as SAGE. Elwood P. Quesada, chairman of the Airways Mod¬ 
ernization Board and later to be the first administrator of the Federal 
Aviation Administration, visited Lincoln to follow up on the proposal. 
Shortly after his visit, James T. Pyle, administrator of the Civil Aeronau¬ 
tics Agency (CAA) visited to express his interest in integrating military 
and commercial air defense and air traffic facilities. 

We relied on Dave Israel in this area, as Dave was our technical 
person on air traffic control. He had continued his interest in air traffic 
control since his thesis and 1949 Air Force study days. Since air traffic 
control had much in common with air defense, we persuaded the Air 
Force, and later the Air Force in cooperation with the FA A, to carry out 
research and planning in this integration. Dave was assigned to the task, 
and he in turn set up a three-man team, including Howard Kirshner, Paul 
Stylos and David Bailey, to pursue the problems. They began to plan a 
series of experiments that became the CHARM (CAA High-Altitude 
Remote Monitor) project after MITRE was formed and took over the 
work. CHARM aimed at demonstrating the possibility of SAGE-ATC 
integration, using the Boston Air Route Traffic Control Center at Logan 
Airport, the ESS radars at South Truro and Bath, and the Whirlwind 
computer in Cambridge (in order not to interfere with SAGE tests involv¬ 
ing the XD-1). This was a diversification into non-military systems work 
that would generate MITRE’s single largest steady source of non-defense 
related funding. CHARM demonstrated that such integration was feasible, 
but, for many reasons — financial, doctrinal, etc. — it would be difficult to 
make it practicable, especially the use of joint command and control 
centers. 

Eventually, the FAA recognized MITRE as its systems engineer, 
and the three-man team was built up in number and transferred to Washing¬ 
ton. Israel stayed at Bedford, while Kirshner, Bailey, and Paul Locher 
moved to Washington to continue MITRE’s ATC work for the FAA. 
Kirshner was effectively the project leader, although he reported to Israel 
in Bedford who was the nominal project leader. Howard had been a part of 
the Cape Cod System design group. He was tall, pleasant and articulate, 
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and he had a lively sense of humor that drew people to him. One could 
always count on him to lighten up meetings. 

Although Israel was the most knowledgeable ATC person we 
had, he tended to run roughshod over the FA A staff who had responsibility 
for air traffic control. I remember being called into the office of the senior 
FA A man in Bedford, who insisted that Israel be fired, or at least be taken 
off the project. I explained that we had every confidence in Israel, and that 
the FA A was free to find another company to support it if they chose to. 
Fortunately, he changed his mind, and our ATC group grew and matured 
until it became a significant part of the support for MITRE’s future 
Washington Operations. 

Even before the idea of the SCC was proposed, alternative ways 
to decrease the vulnerability of the system were being considered. Shortly 
before the formation of MITRE, the Air Defense Command and NORAD 
were beginning to function as a full-fledged command that included a 
strong Deputy for Planning. Under their charter, they had the responsibil¬ 
ity for generating an operational plan for the defense of North America. 
This plan was called the North American Air Defense Operational Plan 
(NADOP). These plans tended to be overly ambitious — the commands 
were charged with the defense role, but were unrealistic in that they did not 
match the budgets granted by Congress. When faced with this situation, 
the Department of Defense had developed an automatic response: set up a 
study to advise the Secretary of Defense on what he should do about these 
plans. These studies were performed by senior volunteers from industry 
and academia. 

One particular such study was assigned to the Weapon Systems 
Evaluation Group (WSEG). WSEG was supported by the Institute for 
Defense Analyses (IDA). The director of research of WSEG was A1 Hill, 
who had left the directorship of Lincoln Laboratory to become vice 
president and director of research for IDA. I had been assigned as a 
Lincoln member of this study. I reported to Hill and found that he was 
pleased that I had been assigned the task. Colonel Lee, however, was upset 
that I had been assigned this task because he felt it was detracting from the 
SAGE software design for which I held responsibility. 

I remember sitting in Hill’s office while a steady stream of other 
industry and university participants dropped in to pay their respects. I 
found that many participants were from the special interest groups protect¬ 
ing their weapon or computer or whatever it was that their companies 
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were producing. I saw this as the main stumbling block to trimming the 
air defense plans to fit the available monies. I hadn’t much experience with 
studies of this sort, so I spent most of my time trying to understand what 
people were doing and believed that I was a disappointment to Hill, even 
though I contributed considerably to the design of the second generation of 
BOM ARC. The upshot of the WSEG study was a pared-down version of 
the ADC’s original NADOP plan. When I left the study, it was nearly a 
repeat of the time when I had left RLE — i.e., Hill didn’t care. 

Lincoln had encouraged and participated in an ADC planning 
study of decentralization as a means of decreasing vulnerability. The 
system that evolved from this study became known as BUIC, for Back-Up 
Intercept Control. The BUIC system was located at radar sites, with 
connections to other radars in the sector. It would be used on a standby 
basis, in the event of an attack on a direction center. BUIC could perform 
SAGE functions, but with limited capacity. Nevertheless, BUIC ensured 
that air defense functions could be carried on if the SAC bases were hit. 
The BUIC system was approved in 1961. In the late sixties and early 
seventies, air defense continued to be important enough to keep some of 
the SAGE divisions operating, but not important enough to make it effec¬ 
tive over a broad range of likely scenarios. The low-altitude problem, for 
example, was left unsolved. 

From 1949 to 1963, the conception of air defense of the conti¬ 
nental United States had changed dramatically. The initial idea was of an 
area defense system able to cause significant attrition on any bomber raid 
up to 1000 raiding aircraft. As ballistic missiles gained emphasis and 
demanded a greater share of the defense budget, the scope of the air 
defense system decreased, and the conception of the role changed from 
area defense to air space policing, warning, and surveillance. This evolu¬ 
tion was to continue at a limited rate, so that all of the SAGE direction 
centers had to readjust their areas of responsibility, and the arguments for 
defense systems conceived by Lincoln were driven from area defense 
toward perimeter defense. 
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CHAPTER 36 


THE WINTER STUDY 


The ADES Project Office in New York was the first system 
program office to be organized around electronics systems as a separate 
entity, rather than as support subsystems to the individual weapons they 
controlled. These electronic systems were centralized and served a variety 
of weapons and sensors and supported many functions previously carried 
on by human operators. These systems, later to become known as com¬ 
mand and control systems, tended to centralize the control and provide 
management support to upper-echelon command and control functions. 
They were evolutionary, constantly in the process of growing and adapting 
to the changing force structure. They also accommodated new and old 
subsystems and thus their management required contact with the upper 
echelons of the various operating commands and had to adapt to changing 
command personnel. There was always a struggle between those people 
who thought of them as serving the sensor-effector terminals and those 
who believed they should substitute for or enhance the management func¬ 
tions of the command. This difference was recognized for the first time in 
the New York Project Office (ADES) and was sharpened in definition by 
the needs for integration first between SAGE and its weapons (and radars) 
and then by the need for automation at command headquarters such as 
North American Air Defense Command (NORAD) and National Military 
Command System (NMCS). 

The concept for the National Military Command System, which 
grew out of the discussions of these matters, led also to the idea that these 
systems ought to be treated differently during the R&D phases. It was 
about the time of this recognition that General Schriever had been named 
head of Air Research and Development Command. He had taken com¬ 
mand about the time that these things were being reviewed at Air Force 
Headquarters in a study called the Becker Study (after the man who ran it), 
and had insisted upon being given a chance to carry on the work within his 
new ARDC structure which included the formation of the Command and 
Control Development Division (C 2 D 2 ). (In 1961, ARDC and portions 
of AMC were consolidated into a new command, Air Force Systems 
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Command. Schriever was put in charge and was given his fourth star. The 
Electronic Systems Division of AFSC was activated at the same time.) 

A study called the Winter Study had been proposed by ARDC in 
late 1959 to look at all systems that could be called command and control 
systems, identify their weaknesses and propose solutions. It was a given 
that these systems would come under the control of ARDC. I was desig¬ 
nated executive director of this study and was teamed with Lieutenant 
Colonel John L. Lombardo, who was then deputy for planning at C 2 D 2 . I 
spent a lot of time on defining the organization and on operation of the 
study, and was assisted by people drawn from MITRE, SDC, and Bell 
Laboratories, as well as from Air Force commands and laboratories. 
Hundreds of people were involved. We started the study in January 1960. 
About a month after we began, Lombardo and I were summoned to 
Boston’s Logan Airport to meet with Jack Ruina, an influential official in 
the Department of Defense. He informed us that the study required the 
guidance and approval of a high-level steering committee and that a 
prestigious study director was to be named. I was annoyed by this turn of 
events because it tied my hands waiting for these entities to materialize. 
The steering committee was formed under the chairmanship of A1 Hill, 
who had been creeping into and out of my life since I joined MIT. Gordon 
N. Thayer, a vice president of AT&T, was named study director and I 
worked with him. 

Prior to Thayer’s arrival on the scene, however, I had to work 
with A1 Hill who was then a patient at a local hospital. Needless to say, this 
was not a satisfactory situation for either one of us. In addition, I was 
substituting for Thayer, whom I didn’t know, and I didn’t feel free to 
negotiate for him. In spite of the awkwardness of the situation, the Winter 
Study did establish a strong connection between the various command and 
control systems, criticizing some and recommending others, and recom¬ 
mended that all should be treated as a class rather than as separate entities. 
It also demonstrated the value of a central system engineering and labora¬ 
tory support facility collocated with the system program offices assigned 
by the Systems Command. This need for laboratory and technical support 
endorsed the concept on which The MITRE Corporation was based. It 
defined in general terms the structure and content of that technical support. 

At the conclusion of the study it was recommended that MITRE 
be changed from an organization that provided support to one system 
(SAGE) to an organization that supported most of the electronic systems 
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being developed at that time by the Air Force. Thus, as the SAGE system 
was coming to the end of its development cycle, it was augmented by the 
North American Air Defense System (NORAD), the Air Force Command 
and Control systems, the Tactical Air Control System, the Strategic Com¬ 
mand and Control System, all topped off by the National Military Com¬ 
mand and Control System (NMCCS). In addition, those systems 
supporting intelligence operations at the commands were added to the 
class, as were weather and air traffic control systems. 

Not everyone was happy with the study or the fact that it was 
going on. Any criticism of what was being done, especially on the com¬ 
mand systems, was bitterly resented by the command in question. I 
remember visiting General Thomas Power, now a four-star general and 
commander of SAC, with Gordon Thayer. Power was cut from the same 
bolt of fabric as was General LeMay, the dynamic, disciplined leader of 
the most powerful strategic force in the world. Our visit was in Power’s 
office. The chairs had been set up in a horseshoe arrangement in front of 
Power’s desk. Thayer was prepared to report on the status of the Winter 
Study. Power didn’t allow him to speak, but insisted that one of his 
deputies, a colonel, do the speaking. This colonel had the most nerve- 
wracking job in SAC and showed signs of stress and fatigue. He used part 
of the time we had to criticize the Winter Study for its evaluation of the 
developing SAC system. The rest of the time was spent in a monologue by 
General Power stressing that SAC Headquarters could design the system 
without help from a committee. Thayer, who had had great experience, 
chose to shut up and listen. In spite of my natural aversion to confronta¬ 
tion, I was wishing that he would more aggressively promote the Winter 
Study findings, but I think in retrospect he made the right decision. 

During the course of the study, we met with the Steering Com¬ 
mittee several times. Some of us felt that Hill had not been able to serve as 
effectively as we had hoped he would in his role as chairman of the 
Committee. However, considering the complexity of the problem and the 
lack of pertinent experience of the Steering Committee members, it should 
not have been surprising that this was so. The last episode in the Winter 
Study story was the report by Hill to the U.S. Air Force Scientific Advi¬ 
sory Board, a group of scientists from industry, academia, and the mili¬ 
tary. Hill delivered a report that did not, in my opinion, reflect fully the 
findings of the study, and which seemed, rather, to be drawn largely from 
his own biases. I also remember this SAB meeting as my introduction to 
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Eugene G. Fubini. Fubini was a bantam rooster of a man, who seemed to 
view the Pentagon as a cockpit where it was necessary to meet every 
challenge with a combination of harassment, upstaging, undercutting, and 
finally, outclassing the rest of the roosters. The remainder of the meeting 
was largely spent placating Fubini. The findings of the Winter Study were 
lost in the shuffle. In spite of the first impression I got of Fubini from this 
meeting, he went on to become the most effective Deputy Director of 
Defense Research and Engineering, and his antics were part of the process 
he used to gain the attention of those in charge of electronics-based 
developments. The report of the Winter Study was never officially 
accepted by the Air Force. Nonetheless, it served Schriever’s purposes and 
prevented further attempts to attach ESD to Air Force Headquarters. 

Although it was frustrating, many good ideas were put forth, and 
the study forced the Air Force and its support people to look at the bigger 
picture. The Winter Study identified many weaknesses in ongoing pro¬ 
grams that were subsequently corrected, using subcommittee recommen¬ 
dations. It set up a management scheme that included participation of the 
operating command headquarters in the design process. It also set a pattern 
for the use of a system engineer, backed up by a laboratory structure. Much 
of the post-SAGE structure of MITRE was influenced by the findings of 
the Winter Study. 
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CHAPTER 37 


THE MYSTIQUE OF SYSTEM ENGINEERING 


An Allegory 

Once upon a time, there was a prince who ruled over a 
small principality beset by dragons. He had a small band of knights 
who fought bravely against the dragons — frequently at enormous 
odds. Because they were valiant knights they frequently won, but 
because the dragons were very fierce, sometimes the knights would 
lose. 

Often the prince thought about the great King Arthur and 
his famous Round Table of invincible knights. If only he were King 
Arthur, he wouldn 't have any trouble with dragons! Then, one day, 
the prince heard that a knight of the Round Table had killed a dragon 
with his bare hands. The prince, excited, determined to travel to 
Camelot to hear of this wonder first hand. 

When the prince arrived at Camelot and had exchanged 
greetings with King Arthur, the conversation turned to a discussion 
of dragons. 

“Is it true that a knight of yours killed a dragon with his 
bare hands?” the prince asked. 

“Quite true,” replied Arthur. 

“Surely, that knight must rank first among all the knights of 
the Round Table,” the prince opined. 

“Not so,” said the King. “In fact, that knight ranks 173rd. 
The knights who rank foremost among the knights of the Round Table 
are those who write the guide books for dragon slaying. As a matter 
of fact, the guide books say that you are supposed to slay a dragon 
with a sword, so killing one with bare hands shows an improper 
understanding of the correct procedure and doesn ’t get very much 
credit. ” 

“Perhaps these guide books are what my knights need,” 
mused the prince. “Do they help your knights kill dragons ? ” 

“They don't really help my knights,” Arthur observed, 
“because I can't afford to equip them with the expensive kinds 
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of swords that the guide books specify. As a matter offact , my knights 
haven V killed many dragons lately — there was the one we were 
talking about that the knight killed with his bare hands , and there 
was another dragon who ate a guidebook by mistake and died of 
indigestion. Not many dragons , to be sure , but it doesn’t really upset 
me because , after all , writing guide books is a far more noble 
occupation for a knight than slaying dragons. ” 

The prince heard all of this with wonder , and soon he 
departed to return to his principality , no longer envious of the 
famous King , but beset with a new worry. If his knights were to 
emulate the prestigious activities of King Arthur's noblest knights to 
share in their fame and glory , who would there be to slay the 
dragons? 


I his allegory, written by a Division 6 engineer, Ed Bensley, 
shows how the attitude toward system development changes as you move 
from first-generation systems to subsequent generations. First-generation 
systems are always fraught with major deficiencies at the component level 
— so all efforts are taken up with making things work, at the expense of 
standardization and integration. Subsequent generations are faced with the 
integration and standardization problems left unsolved because of the first- 
generation approach, and there is always a trend toward trying to attack the 
problem as a whole. This process comes to be known as the system 
engineering process. The “bare hands” approach had been used on Whirl¬ 
wind I and on the Digital Radar Relay; swords were defined for the later 
phases of SAGE. 

As we progressed through the component/subsystem devel¬ 
opment in SAGE and finally the overall system development, people 
gradually gained an understanding of “the system.” They tended to stop 
thinking about vacuum tube characteristics and to start thinking about air 
surveillance. This happened to a majority of the Division 6 personnel. In 
my case, I had had early experience with radars, sonar, and other position- 
location devices in the Navy, but I didn’t think about these as “systems”; 
rather, I thought of them as devices. Also, on Whirlwind III worked on 
components, maximizing performance of the basic functions, such as the 
arithmetic element. As I moved into the Systems Office, however, I 
was forced to treat these devices as subsystems, and the total of these 
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subsystems as a single system. The need for the broader approach was 
driven home for me by the Systems Office experience and by the develop¬ 
ment of the master computer program, which required the integration of 
many functions. 

In the mid-sixties, a similar second-generation effort was taking 
shape in the ballistic missile system area. Minuteman, a second-generation 
system, was alleged to be a top-down system development, and Ramo- 
Wooldridge was the system engineer. Sold on the success of Minuteman, 
the Air Force decided to write the processes into a series of regulations, 
known as the 375 Series. These were based on the assumption that if the 
Air Force were to do another missile, they would go through the same 
procedures and processes, and come out with as successful a product. But 
our experience on SAGE indicated that each system was different enough 
that to be successful one could not regulate the entire process. This was 
especially the case when one turned to command system development. In 
these systems, such as the NMCCS, integration was achieved through a 
communication process that was extremely complex and that could not 
easily be regulated. The command systems had to communicate with a 
variety of other systems, the weapons system being just one. And not only 
did one have to integrate with new systems, one had to accommodate old 
systems that were never retired. Regulating the process had the effect of 
destroying opportunities for innovation on the one hand, and on the other, 
including unnecessary steps, simply because they were steps that had been 
taken on the original Minuteman. This led to the frustrations aptly alluded 
to in the allegory. In spite of our negative feelings about the Department of 
Defense’s regulatory approach to systems engineering, many very compe¬ 
tent people were involved in the thinking that went into the regulation 
process. Those system program offices that were successful treated the 
system regulation for what it was, relying on the pertinent parts, but not 
overlooking the need for deletion and innovation in the system under 
development. 

The concern with systems was influenced by the operational 
research studies carried out by organizations such as RAND and IDA and 
by system studies initiated by industry, academia, and government agen¬ 
cies. By the late 1950s, system engineering became an obsession whose 
manifestation took the form of defining the system engineering process. 
One could always expect that the first part of almost every presentation to 
the military by industry would be a definition of system engineering, 
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which, if applied, would make every prime contractor a system engineer. 
This, along with the application of the 375 Series regulations, made it 
almost impossible to separate MITRE efforts from those of the prime 
contractors. A number of attempts were made to structure the processes 
with enough detail so that one could distinguish the more abstract elements 
of the design from the more concrete. 

A typical experience with this phenomenon was to watch the 
eyes of the people who were being briefed on a prime contract proposal. 
When the definition of system engineering came up, as it inevitably did, 
the eyes of the listener would glaze over and he went into a coma until that 
part of the presentation was finished. There were attempts to distinguish 
between system engineering and “general” system engineering, the latter 
being what was done by the government in concert with the MITRE staff 
assigned to the system project. In my role, I was caught up in this semantic 
labyrinth, and had to be as precise as one could be in order to plan and 
execute MITRE’s role. I remember constructing a briefing on this, for 
which a number of us had designed a system development flow chart. I 
thought it was crystal clear, and expected to receive the kudos of my 
colleagues. I presented it to Halligan, who rose to the occasion and said 
straight out that he didn’t like it. 

Eventually, the SAGE project reached a point at which the 
aggregate of the subsystems could be integrated, and the definition of 
system engineering was replaced by a description of the work. In later 
years, enough experience had been accrued so that a general understanding 
about the need for treating problems of the larger system would be attacked 
at the same time that the problems of subsystems were undertaken. With 
the introduction of integrated circuits, there was enough standardization so 
that top-down design became the rule, rather than the exception. 
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CHAPTER 38 


SUMMING UP 


In the process of solving the problems of the SAGE system, 
there were certain fundamental problems that were solved for the first 
time. These problems occurred at all levels. In the computer design area, 
the implementation of a working real-time control computer dedicated to a 
military mission was successfully demonstrated and implemented. 

Several inventions were realized, among them random access 
core memory, which was by far the most important component to be 
developed. This included not only the concept but also the materials, the 
structure and fabrication techniques. The application of marginal checking 
under machine control to minimize unscheduled downtime was imple¬ 
mented for the first time. The practical data link using phone lines to 
facilitate computer-to-computer and radar-to-computer information trans¬ 
fer was implemented on a large scale. 

Time sharing of a common data base and computation aids were 
both used extensively for the first time. Other innovations included the 
first automatic initiation and tracking of aircraft using radar data; the first 
interactive system employing CRT displays with alphanumeric symbols; 
the first extensive use of computer graphics; the first interceptor direction 
program employing a choice of final phase tactics; the first use of overlap 
coverage to raise the data rate and simplify the handover problem; the first 
dual arithmetic element; the first duplex computer system; one of the first 
radar beam splitters; the first use of the light gun or pencil, and the first 
extensive use of index registers. 

There is also a list of management innovations that are attribut¬ 
able to SAGE. The ADES program office was the first Air Force office set 
up to manage electronic systems as distinct and separate from weapons 
systems. Prior to SAGE, these systems were subordinate to the weapons 
they controlled; SAGE grouped together all of the electronics elements 
under ADES. This would lead to a broader concept, the Worldwide 
Military Command and Control System (WWMCCS), which grew out of 
the SAGE super combat center idea. SAGE represented the first time that 
the Air Force set aside a special team, in this case the 4620th Wing, to 


168 




define, structure and integrate the higher-level command and control 
functions for the Air Defense Command. This approach would become the 
rule rather than the exception. Finally, the Air Force established the 
Electronic Systems Division to handle the ground-based information sys¬ 
tems of all Air Force weapons projects. 

SAGE spawned a number of other management innovations. The 
Systems Office, which I established, led to what is now called “configura¬ 
tion management,” although at the time the concept of configuration 
management of command and control systems did not exist. The idea of 
having a system engineer in an associate contractor role was also new. 
SAGE was the largest scale system engineering job of its time. The system 
engineer — first Lincoln, then MITRE — was in a prime contractor role, 
tasked to pull together all the elements of SAGE. 

The SAGE experience was in its way unique. There were few 
systems of such complexity and scope that were challenging the engineer¬ 
ing community in the U.S. during the 1950s. The missile programs and the 
space programs would come as close as anything to this complexity and 
scope. The ingredients that came together and made the SAGE experience 
what it was seemed to include the following: first, there was an agreed 
upon, generally perceived threat. The Russian bombers were real and the 
atomic bombs were real. The hostile intent of the Soviet Union was also 
clearly demonstrated by its action. In the Lincoln organization, there was a 
second factor. Lincoln was part of MIT and MIT’s reputation and policies 
isolated those who worked on the SAGE design from the interference of 
the government bureaucracy. It made it possible for those to whom the 
problems were presented to efficiently initiate action to solve these prob¬ 
lems. Another factor was the youth of the organization — our ages aver¬ 
aged in the late twenties or early thirties. It was said we were too young to 
know that we couldn’t do what we did. Ken Olsen claimed that naivete is a 
virtue in a revolutionary venture, or in any creative endeavor. 

We found that people made a difference. Engineers are equipped 
by training to make compromises, to make things work, and to improve on 
design. We found that the people who had been responsible for making 
things work, such as the military-trained technician, contributed substan¬ 
tially to the progress. We found that software was as large and complex a 
problem as the hardware. We found that there was a payoff in having 
computer aids to programming, and that SAGE contributed a lot to the 
development of these aids. 
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The Lincoln staff were mostly engineers, and engineers solve 
engineering problems. The criterion for success is whether or not the 
system works, and is only loosely connected to the elegance of the solu¬ 
tion. Thus, there can be a high payoff to conservative design and even to 
brute force design. We often said that we were like road builders. We 
didn’t care where the road took us as long as it supported the traffic. This 
conservative design philosophy contributed to the opinion held by some 
members of the government establishment that we were gold-plating the 
system and not taking into account, sufficiently, the cost. 

In addition to being engineers, the Lincoln staff became systems 
engineers. They started to work on components and subsystems, switching 
their focus as one level (such as basic circuits) was completed and under¬ 
stood, to larger and larger aggregates of subsystems, until they were 
focused on the U.S. air defense system in all its breadth and complexity. 

During the late fifties, one of George Valley’s seminars featured 
Sy Ramo, who had played a very important role in the development of the 
Atlas and Minuteman missile systems. His talk was on systems engineer¬ 
ing and it struck a chord with me. He talked about two kinds of systems 
engineering — systems engineering in the small and systems engineering 
in the large. In the small, he included all of the engineering solutions 
required to connect together and hook up a system (make the electrons 
flow, make the data streams coincide with each other, proper sync pulses, 
etc.). By systems engineering in the large, he referred to not only the 
technical and physical network design, but to all of the sociological, 
financial, budgetary, and other such considerations that go into a system 
that consumes as much of the national treasure as did the SAGE job. I think 
that the Lincoln staff who participated in the SAGE design were provided a 
unique opportunity in that they were able to work in both of these areas. 

My own experience tended toward systems engineering in the 
large, where the objective of the things I did was to bring the various 
constituencies together to rationalize and agree upon the best design, 
taking into account all of these factors. SAGE allowed each of us to seek 
our own functional level and appropriate area. The unity of the program 
depended heavily on each person’s ability to integrate his pieces of the 
puzzle. This puzzle, which I had come across by chance, dominated my 
professional life for more than a decade, and was the foundation of the rest 
of my career. 
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EPILOGUE 


Where is it written that the computer field is evolving so rapidly 
that each new innovation leads, within a short time, to the obsolescence of 
its predecessor? In 1982, a group of old SAGE hands visited the air defense 
direction center in Fort Lee, Virginia. We were surprised to find that the 
FSQ-7 computer was still operating as reliably as it did during its first 
years of operation. The commander at the base was pleased to show us 
around the installation. Although it had been operating for twenty years, 
the computer showed no signs of neglect, and its outstanding reliability 
was still its major feature. The master program, however, had evolved 
considerably from the initial version first prepared by Lincoln. SDC had 
continued to provide computer program maintenance. 

Those of us who participated in the initial design of the system 
were moved by the enthusiastic way the sector personnel spoke about the 
machine, even though they were well aware that the full installation 
required as much as three megawatts of power, and that a new machine 
would require only a minute fraction of the power and space consumed by 
the rack upon rack of vacuum tube circuits. I believe that this longevity is a 
record for large-scale digital control computers. 

During the course of the development of SAGE, each of 24 such 
direction centers were equipped with two FSQ-7s as well, most of them 
along the Canadian border and the East and West Coasts. In January, 1983, 
six were still running, and in January, 1984, all the SAGE computers were 
shut down, to be replaced with more modem machines. Portions of the 
FSQ-7, as well as of Whirlwind, are on display at the Computer Museum 
in Boston, and at the Smithsonian in Washington, D.C. 

The companies and laboratories that were founded initially to 
play a part in the SAGE program have since adapted to live in the 
computer-dominated world. SDC, which was founded to provide the 
computer program for SAGE, was converted to a profit-making company, 
with strong ties still to the software business which they dominated in the 
1960s. It has been acquired by Burroughs and kept as a separate division. 
Lincoln Laboratory, which was set up to solve the air defense problem, has 
switched its focus to satellite communications and anti-intercontinental 
ballistic missile work, and other research problems. The MITRE 
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Corporation shifted its focus from SAGE to other information system- 
based programs at all levels of the military establishment. It has grown 
from the 270 employees who transferred from Lincoln in 1958 to around 
5,000 employees today, and from a single-project company to an organiza¬ 
tion administering some 400 projects. 

IBM utilized the SAGE experience by adapting components and 
subsystems developed for SAGE to their product line. They adopted the 
core memory, for which they endured and lost a lengthy court battle with 
Jay Forrester and MIT over the patent. AT&T profited tremendously from 
the SAGE data link, which evolved into their A-l data service and which 
opened for them a new market in data transmission. The Digital Equip¬ 
ment Corporation is the most famous case of a group of people from the 
staff setting up a new venture; there are many cases where individuals and 
groups of Lincoln and MITRE personnel who participated in SAGE 
formed profit-making companies. 

The SAGE experience affected many people, and in many cases, 
including mine, was the foundation upon which careers were built. Most 
of the people mentioned in these memoirs have had successful careers, 
partly attributable to the SAGE and Whirlwind experience. Jay W. Forrester 
participated in the final settlement of the IBM suit for the core memory 
patent, and then, as a professor at MIT’s Sloan School of Management, 
developed a new field, industrial dynamics, which has attracted interna¬ 
tional interest. Bob Everett, one of the founders of MITRE, became its 
third president in 1969, and held that title until his retirement in 1986. 
George Valley spent a term as chief scientist for the Air Force, and 
returned to MIT as a professor in the Physics Department, where he 
concentrated on evaluating the undergraduate curriculum by taking all the 
undergraduate courses. He is currently writing his own memoirs of SAGE. 
A1 Hill became vice president of IDA and later returned to MIT to head its 
Center for Naval Studies, and most recently, served as chairman of the 
board of the Charles Stark Draper Laboratory. Charlie Zraket stayed with 
MITRE and succeeded Bob Everett as president. Dave Israel left MITRE 
in the late 1960s and is chief engineer of the Defense Communications 
Agency. Halligan retired at 66, after a short term as chairman of MITRE’s 
executive committee. He died in 1975 of emphysema. 

Moose Walquist left Lincoln and became vice president in 
charge of TRW’s satellite communications efforts. Jack Harrington also 
left Lincoln, to become head of MIT’s Center for Space Research, and 


172 



most recently, senior vice president of research at COMSAT Corporation. 
Bob Wieser became director of Advanced Weapons Programs at McDon¬ 
nell Astronautics Company, and is now a private consultant. Amow left 
Lincoln to found Interactive Data, and later Advantage Systems, Inc. 
Steve Dodd was one of the few who remained at Lincoln until his retire¬ 
ment. Norm Taylor left Lincoln to become president of Scientific Engi¬ 
neering Inc., and later vice president of ITEK. Most recently he headed his 
own consulting firm. 

I took a disability retirement after having served as senior vice 
president of MITRE. Pretty good for a country boy from Yellow Jump, 
North Dakota! 
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THE ROMANCE OF PROGRAMMING 


A Speech for 
the SAGE Symposium 
8 November 1956 


Illustrations by the author 




INTRODUCTION 


Xo begin, I would like to say a few words about the title of this 
talk, “The Romance of Programming.” Isn’t that a good title? When you 
read it on the announcement, didn’t it make you want to come? Actually, 
this is going to be a technical talk. The first title we chose for it was, “The 
Application of Heisenberg’s Uncertainty Principle to the Design of Com¬ 
puter Programs for the SAGE Direction Center.” Now you know that 
nobody would come to a talk with a title like that, even if it were 
compulsory. So we tricked you — and here you are, waiting to see movies 
of guided missiles, and we’re going to talk about paper shuffling. Later on, 
we’ll be flashing slides showing partial differential equations and all that 
rigamarole that is the substance of a technical talk. But before we do, 
there’s a rumor that RAND and Lincoln are producing programs for SAGE 
... that the RAND organization and the Lincoln organization are all 
jumbled together in one homogeneous mess — er, mass ... that you can’t 
tell a Lincoln programmer from a RAND programmer except that the 
RAND programmer has a Santa Monica suntan. 

Let me tell you right now that these stories are true, and further¬ 
more, that every one of us should get a real understanding of what is going 
on. I have added this precautionary note because of other rumors which 
have been circulated. Like this: “We hear that you have cut out monitoring 
in the initial master program. We hear the program won’t control weapons. 
We hear that crosstelling has been eliminated.” These rumors are not 
completely untrue. It is a known fact that there are about three women to 
every man in the United States, but I advise extreme care in interpreting 
this data. Of course, we have modified the concept of the program as we 
understood it two years ago; isn’t this the normal procedure for a healthy 
development program? The steps in any development between the concep¬ 
tion of the idea and the completion of the system are like learning to play 
the piano. 
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Melodie in F 
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(SLIDE #1) You can see that the melody is the same, but it gets 
damned complicated, even if it does use the same 10 fingers and keeps the 
same time as it goes along. Early in the development we had to come up 
with a concept of what we were going to produce. We recognized, of 
course, that much of our data was incomplete. Some was not even avail¬ 
able, but we had to get started on a system in order to have something to 
modify and improve. As time went on and as our system began to take 
shape, we found things we had overlooked, other factors we didn’t under¬ 
stand, and still others whose magnitude we couldn’t predict. For example, 
we couldn’t predict the number of instructions required in the final pro¬ 
gram from the two or three pages of description of it contained in the 
Operational Plan. It would be like predicting from his sketches the number 
of rivets required for Frank Lloyd Wright’s “Mile-High” building, 
although there is a feeling among non-building types that builders can do 
this. As each new hurdle was taken, our original system concept changed; 
sometimes slightly, sometimes in major ways. 

In the early days, we had a sort of group delusion. We thought 
our computer was a giant brain. Some people told us it was a computer, but 
we didn’t believe that. It turned out that it was a computer, and what’s 
more, it only had 96,000 registers of drum storage, and 8,000 registers of 
core storage. We learned as we went along. There are things which two or 
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three years ago were matters of opinion, which are now matters of fact. 
There was an opinion that our Operational Specs were too complicated to 
program within the time schedule — this is now a matter of fact. Some of 
our opinions were wrong. We thought that we could produce the program 
with 10 or 15 programmers, so we continued modifying as we learned, as 
in the case of the monitoring function, but we are not eliminating it. We are 
changing our ideas on crosstelling, but we are not eliminating that either. 

Sometimes we are brought up short when we try to answer the 
question of how much can we pay in terms of computer instructions and 
program time for, let us say, one percent additional refinement in systems 
performance. It is very much like the budget — many more items are 
desirable, but you have a fixed amount of dollars to work with, so you ask 
yourself how necessary these items are, desirable though they may be. If 
I’m looking for transportation, should I spend $10,000 for a Lincoln 
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Continental with air-conditioning, or should I buy a Ford? The costs are 
different, but the utility is about the same. What we have been doing is 
going over our program design and substituting Fords for Continentals, 
17-inch screens for 24-inch screens, mouton for mink, and computers for 
“giant brains.” To make this point clear, I will trace through the history of 
the program production and introduce you to some of the people who 
contributed to it, and tell you what kinds of jobs they do, and show you 
what we learned as we went along. 



Slide 2 
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One of the difficulties in preparing this presentation has been 
finding interesting ways of showing programmers at their work. We 
thought we would like to follow the excellent example set by Dr. Overhage 
in an earlier symposium. In his presentation, as you may remember, the 
people in his division were shown at their work in interesting settings. As I 
remember it, one of the fellows working on the Bath radar was shown 
perched precariously 100 feet in the air on a 150-foot radar antenna. This 
was part of his job. There was another shot of a man doing his work inside 
the leg of a Texas Tower. 

We have examined the work postures of our people (SLIDE #2), 
and we find that what they do is sit behind desks, hunched slightly 
forward, chin in hand....thinking!!!!! 
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PROGRAM PRODUCTION 



Slide 3 
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THE PHASES 

IN THE PROGRAMMING JOB 


■Mow we get into the technical part of my talk. 

(SLIDE #3) In this slide, you will recognize the Visual Aid fora 
Technical Talk. It has black boxes and it has lines of flow. We were going 
to use our general-purpose flow diagram instead of this slide, but someone 
has marked it Top Secret and I don’t have the clearance to use it. I’m going 
to give you a few seconds to read the slide and make something out of it. It 
starts at the top and ends at the bottom ... finished? 
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In the summer of 1954, Colonel Oscar T. Halley and his merry 
men flew in from Colorado Springs, briefcases in hand, and sat down with 
us and wrote a book about Air Defense in the United States. They called it 
SAGE. The book (called the Operational Plan) said that SAGE would find 
airplanes in the air and shoot them down with the aid of men and comput¬ 
ing devices. For some of the functions, the book specified how this might 
be done. This is a picture of this Operational Plan (SLIDE #4) — not very 
exciting to look at. It has the usual plot — scientist solves problem; 
engineer and programmer implement solution after terrific struggle. Hero 
lives happily ever after. We are not to that ever after part yet. 

We were a confident crew fresh from finishing the Cape Cod ’53 
and ’54 systems, who, with the help of the 4620th Air Defense Wing, 
wrote a set of specifications which defined the things people were shown 
by the computer, what they could do when they saw these things, and what 
would happen in the computer when they did it. We spelled out the means 
by which these people and the computer gathered and displayed a picture 
of what was going on in the air space around us, and how. they calculated 
the direction in which the interceptor would have to go to catch the enemy. 

This was our Lincoln Continental period. We added air-condi¬ 
tioning, jacks on all four wheels, twin exhausts, aluminum heads, push¬ 
button steering, and fur-lined seat covers. We wrote 20 operational 
specifications covering such matters as radar inputs, tracking, height 
finding, and raid forming. These were supplemented by 13 mathematical 
specifications for the equations and logical decisions which must be made 
in order for the program to do its job. 
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This slide (SLIDE #5) shows what red-blooded American boys 
and girls with a little vigor and imagination can produce — three volumes 
of ops specs and two volumes of math specs. 

About this time, we moved in a crew to worry about the design of 
the computer program and set them down between the five-foot shelf of 
ops and math specs, and another five-foot shelf of machine specs, and told 
them first of all to get familiar with the mechanics of our giant brain, with 
its 100 consoles, 60,000 switches, 32 display categories, 90 display 
assignment bits, 64 light guns, 96,000 drum registers, 8,000 core memory 
registers, and while they were about it, find out what it was that we wanted 
the machine to do. They broke the program into pieces so that many people 
could work on it and it could be operated in the machine, and they made an 
outline of the timing and the table storage. These became the beginning of 
the program specifications. 

One of the troubles with any technical talk is that it lapses into the 
jargon of a particular discipline. The words have no meaning to people 
outside the field. In the next section, I was going to give you a short 
description of the job of producing the program, coding specifications, 
coding, assembly test, and the rest, but it wouldn’t give you the feeling for 
the jobs. After all, these jobs are being done by people and people have 
feelings; you can’t get the feeling for the job of our programmers unless 
you yourself have read the ops specs, and studied the machine specs, 
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designed your program and checked it out. We have searched for a way of 
sharing the programmer’s life with those of you who are not programmers, 
and since we have only a few minutes in which to do it, we have turned to 
the arts. When I was a boy on the North Dakota prairie, John Masefield’s 
poem, Sea Fever , gave me a good feeling for the sailor’s life. Remember? 

I must go down to the seas again, to the 
lonely sea and the sky, 

And all I ask is a tall ship and a star 
to steer her by, 

And the wheel's kick and the wind's song 
and the white sail's shaking, 

And a grey mist on the sea's face and a 
grey dawn breaking. 
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Can’t you just see that sailor on the deck of his ship, chin high, 
drinking in the sea and the sky, loving the challenge of it, full of dignity, in 
tune with his universe? We searched among the programmers for a poet — 
we found bank clerks, jet pilots, school teachers, geologists, psycholo¬ 
gists, Doctors of Philosophy, Russian language teachers, Marine Corps 
chaplains — but no poets. 
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I never saw a Coding Spec 
I never hope to sight one, 

But I can tell you anyhow 
I’d rather sight than write one. 


WAC 



One of our people, who shall remain anonymous, wrote this 
(SLIDE #6). It proves that the minstrel died with the Middle Ages. 
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Finally, we found it — the thing that would communicate to you 
the hopes, dreams, aspirations; the sounds, sight, and feel of the program¬ 
mer life — and we bring it to you now. Let me set the scene: Our 
programmer came to work with us nine months ago, finished the IBM 
programmer training course, was given a program to produce, sits by 
himself in his room ... thinking (SLIDE #7)... 



(Background music begins.) 

Is somethin’ botherin’ you, sonny? You say that you’ve been 
readin’ them books for months, an’ they tole ya they all been changed, an’ 
you can’t find out what this ops spec means, an’ the fella who wrote it 
switched jobs and won’t talk to ya anymore, an’ somebody gave all your 
coding sheets to the man from the clean-up campaign an’ you ran after him 
and pulled ’em out of his bucket, an he bit your finger? An’ somebody lost 
your executive deck in the card room an’ you went down there an’ they 
were cutting it up with a great big scissors? An’ you tole them it took you a 
week to get it ready an’ they slammed the door in your face an’ you heard 
them laffin’ in there, an’ you been waitin’ for six weeks to get on the 
computer to test your program and when you get on, somebody spills 
coffee on your cards and they won’t go through the card reader an’ the 
machine hangs up on drum parities? An’ you dropped a reel of tape an’ it 
goes lickety split down the hall reelin’ out the tape as it goes, an’ people 
step on it? An’ when you get back to the office your supervisor tells you 
they’re cuttin’ out your program anyway, an’ you take your supervisor 
down and shove your test deck down his throat, an’ he’s at the hospital 
havin’ his stomach pumped, an you’re waitin’ for the police to take you 
away ... is that’s what’s botherin’ you, ole timer? 

Well, keep your head up high, take a walk in the sun, remember 
that hard work will overcome obstacles, a penny saved is a penny earned, 
and life is just a bowl of cherries ... (Martial music drowns out the last two 
sentences.) 

* * * 
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We hope that this helps you to identify yourselves with us. 

The writing of the coding specifications was a time of occupa¬ 
tional therapy for us, and marked the end of our Lincoln Continental 
period. At this point, we faced up to the fact that “there was a Ford in our 
future.” 
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In the coding specification, the programmer specified the inputs, 
the outputs, and the complex logical structure connecting them for a given 
program. There are 70 or so of these subprograms in the master program, 
and a coding spec was written for each. This slide (SLIDE #8) shows the 
coding spec files. More than 1,000 documents have passed through these 
coding spec files. The programmer then writes the sequence of computer 
instructions to make the computer do what the coding specs say it should 
do. This process is known as coding and ultimately results in a pile of 
punched cards to be fed into the computer. 


199 




Slide 9 
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(SLIDE #9) This is a stack of 60,000 cards shown next to 
Madeline Carey — as many as in our master program. Placed end to end, 
these cards would stretch from the ground to an airplane flying at 30,000 
feet. Each of the subprograms must be tested to see if it does, in fact, 
provide an accurate communication link between input and output. We 
make up a group of input tables from live and simulated data and we write 
out predicted output results. When the program and its input tables are fed 
into core memory, the computer goes to work and produces an output 
which is compared to the predicted output. This is “parameter testing” the 
program. After the program is parameter-tested, the program’s individual 
subprograms are assembled and tested together at various steps. This 
testing of the assembled set of subprograms is called “assembly testing,” 
and it consists of running the assembled subprograms off of prepared 
simulated tables — keyboard inputs — and simulated radar data. The end 
of assembly testing is to show that the program meets the current idea of 
the operational specifications. 

After assembly testing, the program is integrated with the com¬ 
puter and operators who run the system. This is called “shakedown.” 
When the parts (the program, the people, and the equipment) are all 
working together as a system, evaluation will begin. 

This has been a quick review of the job. To place a time scale on 
it, the operational plan was completed in the spring of 1955; the opera¬ 
tional specifications were completed in the fall of 1955; the program and 
coding specifications were completed in the summer of 1956; the parame¬ 
ter testing and assembly testing are well along. We expect that a portion of 
the program called the Air Surveillance package will be delivered to 
shakedown in December, and the rest of the program will be delivered to 
shakedown and will be installed in the field in June of 1957. Evaluation 
should begin in the fall of 1957, but more of this later. 
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DESCRIPTION 

OF THE PROGRAMMING PROCESS 


I have noticed that many of you in the audience have been 
straining to get the meaning of this technical presentation — many of you 
are asleep. To relieve the strain and build up interest, I am going to tell you 
about us. There are about 360 of us: 280 RAND programmers, and 80 
Lincoln programmers. We occupy space — three wings in Murphy Gen¬ 
eral Hospital, the bottom floor of Building C, the basement of Building F, 
rooms in the field station, rooms in the McGuire Direction Center, and two 
motels painted pink in Kingston, New York. We use almost all of the 
machine time in Building F, we use 14 hours per day of machine time at 
Kingston. 
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(SLIDE #10) This is a view of the IBM Kingston plant — our 
motels are off to the right — we land the Wellesley Apache on the airstrip 
in the foreground. 
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(SLIDE #11) This is the maintenance console of one of the 
machines in the Kingston test cell where we work. 
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We have eight hours per day of computer time at the McGuire 
Direction Center. (SLIDE #12) This is a picture of McGuire from the air. 

Now, to get to us. Again, we run into the problem we had before: 
how can we tell you about us programmers so that you get the feel of it? 
Let’s try it this way ... 
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(SLIDE #13) This is the top view of a programmer. The function 
of the hairy spherical structure closest to you is to think. 


211 




Slide 14 
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(SLIDE #14) This is the front elevation of a programmer — the 
hair on the bottom side of the sphere as well as that on the top side are not 
necessary to the function of the thinker, but resulted from the whim of his 
industrial designer. Some programmers come without either hair. 
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(SLIDE #15) This is the side elevation of a programmer. He is 
held to that chair by a force that increases with the reciprocal of the fifth 
power of the distance from it — this force is subject to his will — and some 
have been known to keep this power on for as many as 14 hours per day. 
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PROGRAMING 

MACH INE 




But of course, this is not the way to tell you about us program¬ 
mers — to know us, you must see us as those who know us see us. To our 
supervisors, we are many-talented, tireless workers, turning ideas into 
reality (SLIDE #16). 
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To our fellow workers, we are part of a team — bound together 
by our common objectives (SLIDE #17). 
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To the computer maintenance man, we are a friendly advisor, 
working with him to find machine troubles (SLIDE #18). 
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And to our wives, we are very much like any other guys to their 
wives (SLIDE #19). 

Now we dive back into our technical talk. Let us pick an example 
of one of the functions which is performed by the program, and show how 
it grew through the years — how this function is an example which 
illustrates my opening statements that as we learn more about the prob¬ 
lems, we must modify our initial concept of what it should be. 

We will select as our example the digital display. The Opera¬ 
tional Plan contains only a few references to digital display. It indicated the 
format that the digital display would have, and how it might be used in the 
performance of some of the SAGE functions. In all, there were two or 
three illustrations, and probably a page or two of meaningful discussions 
of what the digital display would be used for. 
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(SLIDE #20) This is David Robinson Israel, who wrote most of 
the section that pertains to the operation of the SAGE system. He did it all 
with his left hand. 
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ceiling 2500 feet, lowering—► 
visibility 3.5 milowering—► 

northeast runway damaged,_ 

others icy — 

ceiling 800 feet, lowering— 

visibility 1 .5 mi., lowering—► 

ceiling zero-► 

visibility zero--► 



airbase (Bedford), currently open (o), but 
prediction is instrument (i) flying conditions 

Details of present weather conditions 


Details of weather conditions forecast for 
1230 hours, no change in runway conditions 


Details of weather conditions forecast for 
1600 hours, no change in runway conditions 


Fig.64. Detailed Weather for Individual Bases. 
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(SLIDE #21) This is Figure 64 from the Operational Plan. It 
shows a typical kind of digital display. The Operational Plan says that 
detailed weather and forecasts for each base used by the subsector will be 
available to the senior director, senior weapons director, weapons director, 
intercept directors, and other personnel. Display will be selected by base. 
The early estimates of the cost of the digital display function were made 
from the Operational Plan and were based on the experience that we had 
obtained in Cape Cod and what we knew of the FSQ-7. It was not possible 
at the time to estimate with certainty the size this program would be. The 
reasons that we could not were: no one had programmed for the FSQ-7; the 
operation had not yet been specified in detail and agreed to by the Air 
Defense Command; we could not predict our own capability for producing 
these programs efficiently. These things made the estimate at that time 
uncertain by factors greater than two or three; however, there was no better 
estimate. The only way that we could improve the estimate was to actually 
do the work. The work of defining the operational and mathematical specs 
was divided among some 14 people who had previously participated in the 
’53 and ’54 Cape Cod programming job. Decisions about what should go 
in each of the specs was made at meetings such as are illustrated in the next 
slide. 
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(SLIDE #22) Here we see Jack Cahill, Steve Hauser, Charlie 
Grandy, Major Chesler and Dave Bailey reviewing the first drafts of the 
Operational Specification. We argued, fought, screamed at each other, 
disagreed, and finally, agreed on what represented an acceptable specifica¬ 
tion for each of the SAGE functions. We spent eight months writing, 
arguing, defining what the operation should be, and when finally we were 
bleeding and exhausted, we froze the specification so that the next step in 
the production could proceed. 
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This slide (SLIDE #23) shows how concurrence was reached 
with the 4620th Air Defense Wing. Here we see Charlie Zraket, Major 
Janek, and Lieutenant Colonel Stevenson going over in detail the opera¬ 
tional specifications and agreeing on what should be in them. 
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This slide (SLIDE #24) shows the work sheet picked up after one 
of those meetings. Oh! That’s not the right sheet! 
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In addition to the above Mentioned frame counta, a smoothed 
tram count will be camputecP^or all OPT radars and for all IRI radars 
after Basking, as follows t 

IT ■ 15 *1^ n/1 

K m \ n ■ 1 

where IF - smoothed frame count, present 

IFT - smoothed frame count, previous 




\ A : 



„ vj/ ji 


9 . 


D - actual frame .count, present frame, Ur- 

- actual frame count of first frame after a set returns to the 
OH or OVERRIDE status after haring been in the 0P7 or DHAVAIL- 



V'X 

'f y 

?; 


ABLE status. 

When D n is EXCESSIVE (see Section V below), it will not be used to adjust 
IF. IF must never be allowed to exceed the corresponding capacity limit 
_^n SectionIHabove. D n is the data count used for the Radar Data Input 
digital displays described in 6M-377U-1. 

V. EXCESSIVE Data . 

The number of returns received from a radar during any scan 
approximately eqlals the numbeV. oflNiircraft seen by that radar during 
the previous scan. The difference between these two numbers will be 
caused by non-unity blip-scan ratloe/Snon-aircraft returns, multiple 
returns, and aircraft entering or leaving^ 11 ® radar's coverage. 

If the number of radar data from any set, after masking, 
received in any subframe causes the sum of the most recent three con¬ 
secutive subframe counts (frame count) to exceed the smoothed data count 
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(SLIDE #25) There. 

Each of the people who defined one of the air defense functions, 
such as weapons assignment, track initiation, radar inputs, or intercept 
direction, drew up requirements of his need for digital displays, and these 
were summarized without filtering into another document which we called 
an Operational Specification for Digital Display. 


235 




236 






In this slide (SLIDE #26), we show two of the major contributors 
to the program designs, A1 Shoolman and Herb Benington. 

Part of their job was to divide the program into parts so that it 
would work with the machine and so that it could be divided among a 
number of programmers. I would like to spend a few minutes giving you a 
background for what this means. 

To the programmer, the FSQ-7 consists of devices for: 

1. Storing data (tapes; drums and core memory; cards). 

2. Performing arithmetic and logical processes on it (arithmetic element). 

3. Transferring data around among the storage and processing devices 
(drum reading and writing system, etc.). 

4. Bringing in new data and transferring out processed data (buffer drum; 
card machines; display system; output system). 

There are 48 storing, transferring, and processing operations 
built into the control mechanism of the FSQ-7, and the sequence in which 
they are performed is specified in a program of instructions to the machine. 
The job of the programmer is to specify this sequence of instructions. 
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DRUM SYSTEM 
150,000 WORDS 


DRUM SYSTEM 
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This slide (SLIDE #27) shows the storage arrangement of the 

FSQ-7. 

Because each of the 48 operations takes about 12 microseconds 
to perform, the program must be held in a storage device which can supply 
instructions in sequence to the arithmetic element at about 12-microsecond 
intervals, or time will be lost while getting the instructions. Each of the 
instructions contains the location of the data to be processed, and specifies 
what operations should be performed on it. Because instructions are 
performed at 12-microsecond intervals, the data which is to be operated 
upon must also be available at 12-microsecond intervals. The memory 
device in the FSQ-7, which supplies instructions and data six microsec¬ 
onds apart, is the high-speed core memory which in the present machine 
contains 8000 registers. Because our 65,000-instruction program cannot 
fit in core memory, it must be broken up and brought in in pieces called 
subprograms (containing 500-3000 instructions each), along with the data 
on which this subprogram operates. The programs that are concerned with 
bringing in the subprogram, as well as the data on which it operates, into 
core memory must be permanently stored in the core memory at all times. 
Thus, three categories of programs are held in core memory: 

1. The subprogram; 

2. The data on which it operates; 

3. A program that specifies the sequence in which subprograms and their 
associated data are brought in and sent out (which we will call here the 
“program environment control program”). 
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Ideally, the high-speed core memory should be big enough to 
hold the whole program and all of the data used by the system. Thus, 
one would reduce the problem of breaking up the program into pieces, 
and of shuffling it in and out of core memory. 

The whole 65,000-instruction program and the data upon 
which it operates is maintained on the auxiliary drums, and is called 
into core memory in blocks specified by the sequence control program. 
These are blocks of registers arranged in sequence around the periphery 
of the drum. When the program environment control program calls a 
block of these registers into core memory, some time is required for the 
first register in the block to come up under the drum-reading heads. 
This time on the average is 10 milliseconds, or time for about 1000 
instructions to be performed. The FSQ-7 is designed so that the 
arithmetic processes can be performed during this interval; part of the 
designer’s problem is to arrange the sequencing of the program so that 
this time is not lost. 

The problem of designing a program, then, is the problem of 
(1) dividing up the whole program into parts; (2) designing tables of 
data that can be used by the program and its parts; (3) working out the 
logistics to insure that each subprogram and its associated tables are 
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brought in and out at the proper time, and (4) making sure that it is 
possible for the designer who cannot get into the machine to understand 
“what’s going on in there.” 

A broad-brush design was made by Benington and Company, 
and they decided that digital display would be treated as a separate 
function in the computer program. Up to this time, about 30 people had 
contributed in some way or another to the specs for the digital displays, 
and because of the magnitude of the problem of producing the program, 
it had to be divided among 10 different people. I would like to give you 
a feel for the kinds of things that people did while they developed the 
program from the ops and math specs. To do this, I will introduce you 
to the people and show them at the various phases of the work that they 
did. 
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(SLIDE #28) This is Howard Briscoe of Lincoln, whose subsec¬ 
tion was assigned the responsibility for producing the digital display 
programs* 
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The first step in the process is illustrated by Robert Landrigan of 
RAND (SLIDE #29), who is digging through the operational and mathe¬ 
matical specifications. He is looking for things that apply to digital dis¬ 
play. This digging gave him the knowledge in the form of personal notes, 
annotated operational specifications, and operational modification 
requests which formed the framework in which he could specify what his 
program should do. The operational modification request became an 
addition to the operational specification and corrected the inconsistencies 
and filled in the gaps. 
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(SLIDE #30) This slide illustrates part of the second phase in the 
production of the program. This is the writing and coordination of the 
coding specifications. In the picture we see Robert McGill, Howard 
Metcalfe, and George Sioras, all of RAND, coordinating. They have on 
the board the flow diagram for the whole digital display program. 

The inputs to the digital display program are the central tables 
and switch inputs. The switch inputs hold the direct requests for digital 
displays from the consoles and the central tables hold those conditions 
under which a display is forced on an operator. The digital display program 
has subprograms which search the central tables and the switch inputs for 
conditions that require a display be shown to an operator. These are called 
“control subprograms.” The output of these programs is a control table 
from which six digital display make-up programs are controlled. There is a 
make-up program for alarms, for tracks, for monitoring, for geography, 
for summaries and for miscellaneous digital displays. The output of the 
digital display make-up program is a drum image table which is periodi¬ 
cally transferred to the digital display drum. The digital display system 
takes it from there. The product of this phase was in the coding specifica¬ 
tions. For each subprogram (and there were sixteen of these), there was a 
separate coding specification that detailed the inputs and outputs in terms 
of the tables needed and affected by the subprogram, and the detailed 
design of all the communication and all of the sequence requirements of 
the program. 
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The next phase in the operation is illustrated by Robert Meyer of 
IBM (SLIDE #31). Here we see him writing the code that translates the 
coding specification into a sequence of coded instructions. He has pre¬ 
pared a detailed flow chart for a better understanding of the program, and 
he uses it to help him code. The product of this phase is the manuscript of 
annotated code and a completely detailed flow chart that describes what 
the program does. 


249 




Slide 32 


250 






(SLIDE #32) This slide shows Arthur Doll of RAND having his 
cards punched, in the card room. He turns in his handwritten manuscript 
(as illustrated in the preceding slide) along with a card request form. The 
card room prepares a set of cards, one for each instruction (in Hollerith 
code), and runs these cards through a tabulator, which prints the contents 
of the cards so that they can be checked for agreement with the original 
manuscript. The product of this phase is an accurately punched instruction 
deck for the program and a list of instructions and annotations from which 
the programmer can work. 

Although the program itself requires some 60,000 cards, as we 
illustrated in an earlier slide, about 10 times that number, 600,000 cards, 
must be punched while producing the program. The total area represented 
by these cards could cover all the floor space in the Lincoln buildings and 
the RAND buildings. The punchings from these cards would be enough, 
when burned, to boil the 5,000 gallons of coffee that have been consumed 
during the production of the program. 
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The next phase in the program production is illustrated by Jack 
Meyers of RAND compiling his program at the maintenance console 
(SLIDE #33). In this phase, he checks to see that core storage allocations 
for the program and tables are correct. The product of this phase is a stack 
of cards punched in machine language (20 instructions per card) called a 
binary deck, and cards showing where the program is in core storage 
during parameter testing and where it should get its tables. 


253 




(SLIDE #34) This is a picture of Inez Hazel of Lincoln, prepar¬ 
ing parameter testing plans for her subprogram. As we said before, the 
program was divided into subprograms so that it could be brought into and 
operated from core memory. The test of the subprogram is parameter 
testing. During this test, the programmer operates her subprogram with 
simulated tables of input data, and she must bring out not only the results 
of the operation, but an idea of what happened at each step along the way 
so that she can find and fix the trouble. To do this, to bring out a history of 
what happens as the program operates, we use an instrumentation program 
called the “checker,” which records the contents of specified registers at 
specified steps in the operation, so that in the event of a failure during the 
testing, the programmer can, by perusing this record, determine where the 
failure occurred. Mrs. Hazel in the slide is preparing a parameter checkout 
plan for testing her program. She specifies the simulated data required by 
the program and the expected results from testing the program on a data 
matrix. She also specifies the procedures in checking the program and an 
executive deck for telling the checker program what to record. 
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This picture (SLIDE #35) shows Mary Kresge of RAND at the 
printer in the control room in Building F, beginning a parameter test. In this 
phase, the parameter test planning is executed in the machine. The pro¬ 
gram is operated by the checker, and at specified points along the way, data 
is collected and printed out. 
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The printout from a typical program is several yards long, and in 
this slide (SLIDE #36) we see Russell White of RAND analyzing the 
results of the parameter tests. 

The product of this phase is a final correct binary deck, which 
has passed the parameter test and is ready to be assembled with the rest of 
the subprograms. 

I suppose you’ve been wondering why I told you this shaggy dog 
story. Perhaps you feel there is a point to it. Perhaps you think I’m not 
finished. We could go on and tell you about the secret ceremonials that the 
programmers hold at midnight at the maintenance console, the coming of 
age ceremony when the programmer finishes his first parameter test, the 
graduation to opinion leader, the dance of the section chiefs. All of this 
would be interesting and you would learn more about us from it, but this 
story does have a point and the point is this: we didn’t know how much we 
would have to change the concept of our program until the coding was far 
enough along so that our estimates were sound. 

In our example of the digital display, the people doing the work 
we described produced a program with 14,000 instructions in it, and this 
was just one of the program functions. The other functions were radar 
inputs, tracking, height-finding, situation displays, switch interpretation, 
etc. Digital displays had 16 out of 75 or so subprograms. The other pro¬ 
gram functions grew in the same way, and when we totalled the instruc¬ 
tions up, we found that we had some 85,000, plus 22,000 registers for 
tables, plus 10,000 instructions for instrumentation, plus 5,000 instruc¬ 
tions for forward telling, standby duplex, and automatic crosstelling. This 
totalled about 120,000 instructions. Now the auxiliary drums in the FSQ-7 
have about 96,000 registers, so our program design was about 25,000 
instructions bigger than it should have been. Did we cry? Did we tear our 
hair? You’re damned right we did. But this is not too bad a miss in an 
estimate that had so many uncertainties in it. Obviously, something had to 
be done, so what we have done is to go over our program, as I told you in 
the beginning, and we have taken off the jacks on the four wheels, we have 
taken off the seat covers, we have made do with one cigarette lighter. In 
short, we are buying a Ford. 
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EFFECT ON PROGRAMS 


PROGRAMS 

DP CONTROL PROGRAMS 

CONTROL REQUESTS 
CONTROL FORCED DD's 
SLOT ALLOCATION 

DP SUBROUTINES 

ALARM LIGHTS 

CONFLICTING DD's 

FORCED DD's 

ILLEGAL ACTION CHECK 

CONTROL WORD MAKEUP 

PARTIAL CONTROL WORD MAKEUP 


DP MAKEUP PROGRAMS 
ALARM DD's 
GEOGRAPHY DD's 
TRACK DD's 
SUMMARY DD'S 
MISCELLANEOUS DD's 
MONITOR DD'S 

CENTRAL TRACK BOOKKEEPING 
CTB 


PREVIOUS LENGTH SAVINGS 


’ 1672 610 

2000 530 

425 250 


79 NONE 

584 500 

100 20 

30 30 

250 50 

37 NONE 


1638 1000 

1703 310 

1940 400 

1395 680 

1566 500 

646 646 

698 500 

14,763 6.026 
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This slide (SLIDE #37) will give you an idea of where we made 
the savings in digital display. 

The control programs and subroutines, as I said before, are those 
programs which sense for conditions under which a digital display is 
shown to an operator. The savings that were made in these programs were 
due to a simplification and standardization of the information content and 
the rules for routing displays to particular stations. The digital display 
makeup programs, as we explained before, collect the data and make up 
the displays to be shown at particular stations. In alarms, the savings were 
due to a simplification and standardization of all alarm digital displays in 
the direction centers. The remaining savings in the makeup programs were 
due to the elimination of digital displays with limited utility and the 
simplification of other displays. For example, the tote that contained a 
summary of the number of tracks of each identity, and the tote that 
contained a summary of the weapons assignment status of the hostile 
tracks in the direction center were combined into one tote, serving both 
purposes, effectively eliminating one of the totes. We eliminated the tote 
that gave the detailed information on raids and groups (how many aircraft, 
mean speed and mean altitude, etc.), because all of this information is 
easily available on the situation display. And so we will continue to go 
through the program, standardizing, eliminating redundant information 
wherever we can, improving the efficiency of the operation itself. We 
expect that at some point when we have the time, we will be able to get a 
substantial saving by reprogramming in the light of what we have learned 
in the first pass through the program. We can’t do much of this, however, 
because it takes time to go through this process for each program, so most 
of our changes will be in the form of elimination. 
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CONCLUSION 


I hank you for coming over and listening to this speech. We 
never did get around to the differential equations and the technical talk that 
I promised you, but I think that we have made our points. We are doing 
what we must do. 

(SLIDE #38) Note that she is as roomy as the Lincoln Continen¬ 
tal, she can go as fast on the highways, and we can get her in our garage. 


THE END 
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The SAGE air defense system was the first military 
system to be substantially controlled by a large-scale, 
real-time digital computer. Among the SAGE 
computer firsts were: 

• Random-access magnetic core memory 

• Real-time operating system with task sequencing 

• Computer networking 

• Digital transmission o\%r telephone lines 

• Computer-driven displays 

• On-line terminals 

• High-reliability computation 

• Duplex computers 

• Marginal checking 

• Software debugging tools 

• Automatic data description language (COMPOOL) 

• Computer graphics 

• Digital.signal processing 

• Digital track-while-scan 

• Digital real-time system simulation 

• Light gun input 




